tag:blogger.com,1999:blog-8086052983184217440.post2175350653390749843..comments2022-11-29T11:22:19.101-05:00Comments on Paul Stadig: Thou Shalt Not Lie: git rebase, amend, squash, and other liespaulhttp://www.blogger.com/profile/14647609048389725132noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-8086052983184217440.post-50156679724223203212013-06-12T13:37:31.334-04:002013-06-12T13:37:31.334-04:00A counter to this article is izs's git-rebase....A counter to this article is izs's <a href="http://blog.izs.me/post/37650663670/git-rebase" rel="nofollow">git-rebase</a>.<br /><br /><i>Rebase is a tool that can be used to arbitrarily edit the commit history. If that sounds universally scary or bad, I’d argue that your understanding of “edit” and “history” are perhaps a bit limited.</i><br /><br /><b>tl;dr:</b> Embrace the difference between draft & published history. Don't edit published history.Johnhttps://www.blogger.com/profile/13442511887203192364noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-67039758537857556902013-01-14T09:53:56.410-05:002013-01-14T09:53:56.410-05:00Thanks for the post. I know it's old, but I st...Thanks for the post. I know it's old, but I still refer back to it from time to time.Jason Rogershttps://www.blogger.com/profile/03512788621802164511noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-89373266589324916282012-02-28T10:04:40.881-05:002012-02-28T10:04:40.881-05:00Excellent post Paul.
I have had misgivings about ...Excellent post Paul.<br /><br />I have had misgivings about rebasing ever since our team began losing commits. It's a way to easily get in trouble, especially if you resolve conflicts on the fly. I had outlined some of these problems in this post:<br />http://blog.codesherpas.com/on_the_path/2010/10/git-rebase-in-anger.html<br /><br />If I were to disagree with anything, I would say that amending a commit that has not been pushed is fine. It's the do-over for a commit that was a mistake (mostly if I ever forget to include some important details in a commit message).<br /><br />Git is currently my preferred version control, but the ability to change repository history worries me. That's why I believe the next great version control utility will be something like git, but without the dangers of rewriting the repository history.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-20394662174014474172011-02-17T09:31:01.848-05:002011-02-17T09:31:01.848-05:00Thanks for sharing your thoughts. I appreciate yo...Thanks for sharing your thoughts. I appreciate you sharing Linus' opinion on the subject, but his opinion is not binding.<br /><br />I work daily on a project with 9 other developers where we have lots of topic branches and merges, and they don't "pollute" the repo, or if the do its an issue of personal taste. Preserving the history of particular lines of code is important.<br /><br />There are different opinions on the topic of one large commit vs. lots of small commits. Personally I find it easier to digest commits when the are complete ideas, instead of half-thoughts, so I tend to fall on the side of largeish feature commits (as you do).<br /><br />By the way, it is totally unnecessary to have a single commit per feature if you are doing it only to have an easy way to revert that work. You can do `git rebase -i -p -s subtree SHA` and it will allow you to remove a no fast-forward merge all at once, in other words, you don't have to remove every commit individually.<br /><br />This is one of the benefits of doing merges vs rebasing. If you rebase your work into mine and we've moved on to other changes *then* it is impossibly messy to revert your work later. However, if you do a no fast-forward merge, I can easily come back later and remove your whole branch from the history in one fell swoop, if you're into that sort of thing.paulhttps://www.blogger.com/profile/14647609048389725132noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-36073131697617581032011-02-16T12:27:49.341-05:002011-02-16T12:27:49.341-05:00This sounds to me as more of a Rant than anything....This sounds to me as more of a Rant than anything. Take it from Linus Torvalds himself. he told me to tell you that you are doing it wrong. http://lwn.net/Articles/328438/<br /><br />I think when people rant about rebasing being bad it's because they've never been in a situation of more than 2-3 developers where erroneous merge commits and endless feature branches pollute the repo. I for one (along with Linus) am for the single commit per feature. It's EXTREMELY EASY to revert a single commit. A feature doesn't do what is expected in production? Great yank it out (git revert) keep moving along. Try unwinding a merge. Things get ugly.<br /><br />My $0.02<br /><br />Snuggs<br /><br />Innovative-Studios.comRa'Shaunhttps://www.blogger.com/profile/04907793680556674870noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-44254002144654225792010-12-08T05:37:16.340-05:002010-12-08T05:37:16.340-05:00@chnicola It certainly seems uncontroversial to sa...@chnicola It certainly seems uncontroversial to say "don't rewrite public history", since even my critics agree with that. I did say this in the Epilogue.<br /><br />However, there are things which even when done in private can make things harder for you, and others once you make it public.<br /><br />For instance, rebasing a topic branch on a newer version of master. If there are lots of changes and conflicts, then it is certainly easier on yourself to just merge master in, instead of rebasing. That way you save yourself from the conflict flogging that git gives you for each commit that you are rebasing. Technically you could rebase because its not public, but the argument for merging the new master in is entirely practical and the argument for rebasing on the new master is entirely cosmetic.<br /><br />Second, the last form of lying (retroactive commits), if done without verifying that those commits compile and/or pass tests can cause problems with `git bisect` and conflict resolution when those commits are made public later.paulhttps://www.blogger.com/profile/14647609048389725132noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-84897419612856354442010-12-08T01:50:35.890-05:002010-12-08T01:50:35.890-05:00It is worth really stressing (which I missed in yo...It is worth really stressing (which I missed in your entire post) that lies only matter if you are sharing a repository. If you are working locally these are useful and sensible tools to use and work with.Chris Nicolahttps://www.blogger.com/profile/00427805306827828707noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-60652196702679229522010-12-07T22:04:40.038-05:002010-12-07T22:04:40.038-05:00>It does not undermine anything: you can do a p...>It does not undermine anything: you can do a partial commit (to the index), stash the rest of the changes while keeping the index.<br /><br />>Then run the test suite to make sure that your (staged) commit is OK. Commit and repeat.<br /><br />@sigi uhhhh...I think we agree. The behavior that I said undermined `git bisect` and the ability to verify conflict resolution by compiling and running tests is breaking things into commits *without* running the test suite for each commit.<br /><br />If you are running tests on (or at least trying to compile) each commit, then cherry-pick and bisect are much more useful, and you can trust your conflict resolution a little more than not.paulhttps://www.blogger.com/profile/14647609048389725132noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-79723715098681071642010-12-07T21:31:24.042-05:002010-12-07T21:31:24.042-05:00"I bemoaned choosing to commit individual fil..."I bemoaned choosing to commit individual files out of a bunch of changes because it undermines the ability to compile and test commits, which is useful (essential?)"<br /><br />It does not undermine anything: you can do a partial commit (to the index), stash the rest of the changes while keeping the index.<br /><br />Then run the test suite to make sure that your (staged) commit is OK. Commit and repeat.<br /><br />The same goes when splitting commits after the fact ("lying"). One can always make sure that the test suite completes after every new commit made.<br /><br />Of course this is impractical with a long running test suite, but then in this case so is committing frequently.Sigihttps://www.blogger.com/profile/13560728705152464043noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-29410217327943286152010-12-07T21:24:33.697-05:002010-12-07T21:24:33.697-05:00Some remarks on what eat-a-git said above:
Hunk b...Some remarks on what eat-a-git said above:<br /><br />Hunk based commits are supported by Git. I agree that they are useful for organizing your history. However, one must be disciplined about stashing before every commit ("git stash --keep-index") and running the test suite in order to make sure the partial commits are legit.<br /><br />Otherwise one does break "git bisect", as the article correctly points out.<br /><br />Fully agree on your second point.<br /><br />Very nice article, worth thinking about.Sigihttps://www.blogger.com/profile/13560728705152464043noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-51349903961645084902010-12-07T17:47:39.191-05:002010-12-07T17:47:39.191-05:00@Mahmoud IMO, what one should do instead of rebasi...@Mahmoud IMO, what one should do instead of rebasing is just merge into your topic branch. You resolve all the conflicts at once, instead of having git repeatedly flog you with conflicts for each commit. And git can still easily tell you where commits came from and where they went.<br /><br />@Jlouis I think this is kind what I was getting at with my talk about integration branches at the end.<br /><br />@Douglas I agree, I think I did mention stashes as a way to set aside some changes to go make changes elsewhere.<br /><br />@eat-a-git I don't think I ever said cherry-picking is a lie. Perhaps I implied it? Cherry-picking is useful, and having commits that compile and pass tests make cherry-picking much more pleasant.<br /><br />I did not bemoan squashing because of their mud patch nature. I bemoaned them because they create new commits which destroys cool features of git. I bemoaned choosing to commit individual files out of a bunch of changes because it undermines the ability to compile and test commits, which is useful (essential?) in `git bisect` and in resolving conflicts.<br /><br />And I guess I'm glad to know I have your seal-of-approval. Thanks, dude!paulhttps://www.blogger.com/profile/14647609048389725132noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-51394311474432030292010-12-07T16:32:02.756-05:002010-12-07T16:32:02.756-05:00Point 1:
Cherry-picking to produce commits is not...Point 1:<br /><br />Cherry-picking to produce commits is not lying. It is organization. Darcs lets you do this for each hunk it encounters and it is an incredibly useful feature which allows to make very concise patches rather than balls of mud.<br /><br />Previously you bemoaned balls of mud patches from squashing, but to have work uncommitted and then to choose which files you're committing at one time is not lying.<br /><br />Point 2:<br /><br />Really most of this lying could go away if there was better annotation and organization, allowing you to abstract what happened while still allowing users to dig down into the history.<br /><br />The article is fine otherwise.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-25766135149510194062010-12-07T14:45:49.765-05:002010-12-07T14:45:49.765-05:00Re: retroactive commits: you can use git stash to ...Re: retroactive commits: you can use git stash to hide away bar while you prepare to commit foo. Much safer than committing blindly.Douglashttps://www.blogger.com/profile/08041010789564868324noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-19921614190425895442010-12-07T13:24:30.862-05:002010-12-07T13:24:30.862-05:00The trick is to have rules on certain branches whe...The trick is to have rules on certain branches where the contract is you wont lie.<br /><br />On other branches, personal ones for instance, you can lie to yourself to a certain extent. Blindly rebasing your own branches to "keep them up to date" is bounds for trouble though.Anonymoushttps://www.blogger.com/profile/02990737394952724516noreply@blogger.comtag:blogger.com,1999:blog-8086052983184217440.post-14619521647540250642010-12-07T11:10:29.753-05:002010-12-07T11:10:29.753-05:00Could you speak a little to what one _should_ do i...Could you speak a little to what one _should_ do if these options are to be avoided?Mahmoud Hashemihttps://www.blogger.com/profile/00508211997310717378noreply@blogger.com