Very good tutorial for those who do not simply want to learn some commands, but want to *understand* how git is working. This was what I was looking for.
Since dropbox treats symlinked folders like a real subfolder, it could technically do anything to the files inside it including deleting them. I've never heard of anything like that happening, but for peace of mind I keep a nightly backup-and yes, it is on an external USB hard drive. I use SuperDuper to do the scheduled backup for my Mac. You really should always keep a regular physical backup of your machine besides any cloud backup like dropbox. :)
Don't use it as a multiuser solution and obviously wait for it to sync before moving to another computer. But beyond that it works great. I've used it without a glitch for years. As long as you treat it as a local repository that happens to have cloud backup, you're fine.
It's not a term I've run into, but my guess is: yes, but I think the term is confusing. To elaborate a little: in git terms, HEAD is a reference to the top of the current branch (tree). HEAD is changed as you commit and move between branches and such. I illustrate some of this elsewhere in the talk. Personally, I would name headless nodes "dangling", that is does not have anything pointing to it. In practice, this should only result from "history rewriting" operations like rebase.
At the link to the slides, I get the message: "This SlideShare was suspended because it violated SlideShare Terms of Service and/or Community Guidelines. You can view more SlideShares here."
Curious. I never got any notification so I don't know why it was removed and it's not even listed on my account anymore. To be fair, I haven't logged into SlideShare in almost a decade. In any event, I put a new link in the description.
Thanks for your reply. If I understand correctly, if something went wrong with Dropbox, it'd only affect the symlink and not the project folder it points to, so I need not worry about that. Or perhaps I'm missing the point? When you mention running a nightly backup, do you mean to somewhere other than Dropbox? Sorry about all the questions!
is 20:30 an example of a headless blob? (not sure if this will be mentioned soon) I keep running into headless VMs, headless commits, but I'm not sure if I understand what being headless is yet
Could you elaborate on why you'd do this? Working on my own, I have my project repo backed up by Dropbox (symlinked to my Dropbox folder, so the repo can be located anywhere on my hard drive). What's the advantage of having two repos and pushing/pulling between them?
12 лет назад
at 37:00 this is not equivalent to a svn reintegration merge. It's just an ordinary merge. it would be a reintegration merge if rev 29fcb and 1ebc5 had been swapped
Great talk. But I still have this question: If you maintain this permanent support branch will you create one for each version listed in the master branch and then discard veeery old support branches in case you don't support the version anymore?
Yes, but only if your customers/clients expect support on old versions. You would likely only have support branches for major versions, for example: 1.x and 2.x, while 3.x is the latest major release. It seems excessive to have support branches for 1.0, 1.1, 1.2, 1.3, etc. because presumably your users can just upgrade to the latest 1.x for free. It's probably acceptable to tell them that if they want fixes they need to upgrade. But it also comes down to you making decisions based on how much pain is involved. At some point you might say, well the 1.x branch is out of support now. For continued support, upgrade to the latest version. Of course, every situation is different so it's really up to you and how you handle support on your project.
There's no huge advantage over what you're doing, other than if something went wrong with dropbox, there'd be no safe copy. I suppose there's also the potential issues of lots of changes hitting dropbox continually (depending on what kind of project it is) instead of just syncing commits, and also some projects may have very large data files that you don't want in source control or dropbox. That said, these days I usually have my project folder in my dropbox folder and run a nightly backup.
11 years later and i still recommend this video to everyone.
Very good tutorial for those who do not simply want to learn some commands, but want to *understand* how git is working. This was what I was looking for.
Best Git tutorial I have come so far!
Thanks for the video. My team is moving to Git from SVN and this really helped me to get a feel of what is going on.
Great Tutorial! Thanks for sharing.
Since dropbox treats symlinked folders like a real subfolder, it could technically do anything to the files inside it including deleting them. I've never heard of anything like that happening, but for peace of mind I keep a nightly backup-and yes, it is on an external USB hard drive. I use SuperDuper to do the scheduled backup for my Mac. You really should always keep a regular physical backup of your machine besides any cloud backup like dropbox. :)
Don't use it as a multiuser solution and obviously wait for it to sync before moving to another computer. But beyond that it works great. I've used it without a glitch for years. As long as you treat it as a local repository that happens to have cloud backup, you're fine.
It's not a term I've run into, but my guess is: yes, but I think the term is confusing. To elaborate a little: in git terms, HEAD is a reference to the top of the current branch (tree). HEAD is changed as you commit and move between branches and such. I illustrate some of this elsewhere in the talk. Personally, I would name headless nodes "dangling", that is does not have anything pointing to it. In practice, this should only result from "history rewriting" operations like rebase.
I've linked to the slides in the video description. Thanks!
At the link to the slides, I get the message: "This SlideShare was suspended because it violated SlideShare Terms of Service and/or Community Guidelines. You can view more SlideShares here."
Curious. I never got any notification so I don't know why it was removed and it's not even listed on my account anymore. To be fair, I haven't logged into SlideShare in almost a decade. In any event, I put a new link in the description.
This is AWESOME!
Thanks for your reply. If I understand correctly, if something went wrong with Dropbox, it'd only affect the symlink and not the project folder it points to, so I need not worry about that. Or perhaps I'm missing the point?
When you mention running a nightly backup, do you mean to somewhere other than Dropbox?
Sorry about all the questions!
is 20:30 an example of a headless blob? (not sure if this will be mentioned soon) I keep running into headless VMs, headless commits, but I'm not sure if I understand what being headless is yet
Thanks for the tips :)
Could you elaborate on why you'd do this? Working on my own, I have my project repo backed up by Dropbox (symlinked to my Dropbox folder, so the repo can be located anywhere on my hard drive). What's the advantage of having two repos and pushing/pulling between them?
at 37:00 this is not equivalent to a svn reintegration merge. It's just an ordinary merge. it would be a reintegration merge if rev 29fcb and 1ebc5 had been swapped
This is great. I don't suppose these slides are available?
Great talk. But I still have this question: If you maintain this permanent support branch will you create one for each version listed in the master branch and then discard veeery old support branches in case you don't support the version anymore?
Yes, but only if your customers/clients expect support on old versions. You would likely only have support branches for major versions, for example: 1.x and 2.x, while 3.x is the latest major release. It seems excessive to have support branches for 1.0, 1.1, 1.2, 1.3, etc. because presumably your users can just upgrade to the latest 1.x for free. It's probably acceptable to tell them that if they want fixes they need to upgrade.
But it also comes down to you making decisions based on how much pain is involved. At some point you might say, well the 1.x branch is out of support now. For continued support, upgrade to the latest version. Of course, every situation is different so it's really up to you and how you handle support on your project.
There's no huge advantage over what you're doing, other than if something went wrong with dropbox, there'd be no safe copy. I suppose there's also the potential issues of lots of changes hitting dropbox continually (depending on what kind of project it is) instead of just syncing commits, and also some projects may have very large data files that you don't want in source control or dropbox.
That said, these days I usually have my project folder in my dropbox folder and run a nightly backup.
I always push as I´m paranoid of data loss
@2:35 LMAO =D
Never ever use Dropbox for git repos.
Why the fuck would anyone use dropbox for git repos o.O