11–20 of 65 posts
Being able to pick and choose (and even edit) individual chunks to be staged is enormously useful. Quite possibly my favourite feature of git.
"Split off a logical chunk from your mess, stage it" should really be another box with "git add -p". Being able to pick and choose (and even edit) individual chunks to be staged is enormously useful. Quite possibly my favourite feature of git.
What does "I don't think it means what you think it means" refer to?
Let's say you are working on a feature branch and you accidentally commit it to the upstream branch before you're ready. Intuitively, you might then revert the merge changeset, continue working on your feature branch for a while, and then when you're done, merge it back upstream.
That would be wrong.
What will actually happen is that when you do the second merge, only the changes you made after the reverted merge will be applied to the upstream branch. All the work that was "reverted" in the initial mistaken merge will be missing, even after the second merge! This can be very confusing, since there's no indication to the developer where it went. It's just gone.
The fix at that point it to revert the revert changeset. But the real solution is to never revert a merge.
"Split off a logical chunk from your mess, stage it" should really be another box with "git add -p". Being able to pick and choose (and even edit) individual chunks to be staged is enormously useful. Quite possibly my favourite feature of git.
sadly, my company decided to move just to use pull requests as a poor man's code review tool. sigh. I'm the 99%
"Split off a logical chunk from your mess, stage it" should really be another box with "git add -p". Being able to pick and choose (and even edit) individual chunks to be staged is enormously useful. Quite possibly my favourite feature of git.
Lots and lots of rebase -i.
What does "I don't think it means what you think it means" refer to?
Would you like to know more? http://knowyourmeme.com/memes/you-keep-using-that-word-i-do-...
git is only good for people that was working like Linus. if you didn't have been accepting patches by email but instead had a fluid svn, perforce, etc central repository and people already collaborating with commit powers, then if you move to git "just because" (which is the reason of 99% migrations) you're going to have a bad time. sadly, my company decided to move just to use pull requests as a poor man's code revi…
1. Not having to check out files means I can work offline.
2. When working on multiple features, it's much easier to create a new Git branch than it is to create a new Perforce workspace.
3. People really tend to abuse Perforce's 'lock file' feature. I'm glad this isn't possible in Git.
4. I haven't really noticed any drawbacks to the pull-request feature. You can still review and comment on diffs on Github.
5. It's the version control of choice for open source software, so if you use any third-party libraries (and I hope you do!), you'll probably need to know how to use Git anyway.
I can't really think of anything I miss from Perforce.
Edit: these advantages are not specific to Git, but any distributed version control system. If you find Git to be too difficult, don't worry, it's not the only game in town. I've heard Mercury is much easier to pick up. Good luck!