4 ms·

> If I haven't made any more tweaks to my change in the meantime then I'm ok, I can just "git reset --hard HEAD^" to discard my coworker's change. You can use

by ithkuil 15y ago

> If I haven't made any more tweaks to my change in the meantime then I'm ok, I can just "git reset --hard HEAD^" to discard my coworker's change. You can use "git rebase -i" to remove the unwanted commit from the history. Git rebase is very powerful, definitely worth mastering.

rwmj 15y ago
This. In fact we have a policy of never using merge, but always using rebase (to the point where we think 'git pull --rebase' should be the default action of pulls).
- lparry 15y ago
  +1, although we use "git fetch origin && git rebase -p origin/branchname" to avoid the nasty behaviour of 'git pull --rebase' where it rewrite all commits of a merged branch on the current branch instead of just redoing the merge commit. Looking back at a 18 month old part of the history and seeing (feature branch x was merged here) is far more helpful than finding a bunch of duplicate commits IMHO
- ithkuil 15y ago
  yes, using rebase to avoid spurious merge commits is also a useful practice, but I was referring to "git rebase -i" (interactive), which can be used to remove commits, splitting/squashing commits, editing commits etc. Sometimes you just don't have time to do clean commits (by committing only relevant changes with "git add -p"), or you fix something later which was logically part of a previous commit. Being able to curate the commit history or your local clone, besides pure aesthetics, allows you to present a given contribution to other team members so that they can better understand what you wanted to do and perhaps review the commits.
haberman 15y ago
> You can use "git rebase -i" to remove the unwanted commit from the history. True, but now you're forcing the user to make a bunch of yes/no decisions about what should be kept and what should be discarded. If you make the wrong decision at any point you can lose your work! (I can't remember off the top of my head if Git keeps a tag for the pre-rebase state, but if so that's a lot of clutter that would accumulate over time). And the VCS still hasn't helped you determine what lines of development are independent of each other. The workflow I am envisioning lets you visually see your working directory as a bunch of independent lines of development. Before you do anything, you can see that your coworker's change is independent of your own changes (because the VCS has analyzed the changes and knows that this is so), which gives you confidence that you can easily remove his change without affecting any of your changes. Then you have the option to simply remove his change, and it's gone.

by ithkuil 15y ago

rwmj 15y ago

This. In fact we have a policy of never using merge, but always using rebase (to the point where we think 'git pull --rebase' should be the default action of pulls).

lparry 15y ago
+1, although we use "git fetch origin && git rebase -p origin/branchname" to avoid the nasty behaviour of 'git pull --rebase' where it rewrite all commits of a merged branch on the current branch instead of just redoing the merge commit. Looking back at a 18 month old part of the history and seeing (feature branch x was merged here) is far more helpful than finding a bunch of duplicate commits IMHO
ithkuil 15y ago
yes, using rebase to avoid spurious merge commits is also a useful practice, but I was referring to "git rebase -i" (interactive), which can be used to remove commits, splitting/squashing commits, editing commits etc. Sometimes you just don't have time to do clean commits (by committing only relevant changes with "git add -p"), or you fix something later which was logically part of a previous commit. Being able to curate the commit history or your local clone, besides pure aesthetics, allows you to present a given contribution to other team members so that they can better understand what you wanted to do and perhaps review the commits.

haberman 15y ago

> You can use "git rebase -i" to remove the unwanted commit from the history. True, but now you're forcing the user to make a bunch of yes/no decisions about what should be kept and what should be discarded. If you make the wrong decision at any point you can lose your work! (I can't remember off the top of my head if Git keeps a tag for the pre-rebase state, but if so that's a lot of clutter that would accumulate over time). And the VCS still hasn't helped you determine what lines of development are independent of each other. The workflow I am envisioning lets you visually see your working directory as a bunch of independent lines of development. Before you do anything, you can see that your coworker's change is independent of your own changes (because the VCS has analyzed the changes and knows that this is so), which gives you confidence that you can easily remove his change without affecting any of your changes. Then you have the option to simply remove his change, and it's gone.