{"thread":{"id":"29169","subject":"How to commit incomplete changes?","startedAt":"2011-12-14T23:24:33Z","lastAt":"2011-12-16T12:58:12Z","messageCount":10,"participants":["Hallvard B Furuseth","Alexey Shumkin","Neal Kreitzinger","Junio C Hamano","Tomas Carnecky","Hallvard Breien Furuseth"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"181195","messageId":"4cfc9cf0515b1bc751f6aa0de4f55e2a@ulrik.uio.no","threadId":"29169","inReplyTo":null,"subject":"How to commit incomplete changes?","fromName":"Hallvard B Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2011-12-14T23:24:33Z","receivedAt":"2011-12-14T23:24:33Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":" Do people have any feelings or conventions for how and when to publish\n a series of commits where the first one(s) break something and the next\n ones clear it up?  I've found some discussion, but with vague results.\n\n I'm about to commit some small edits which go together with bigger\n generated changes.  It seems both more readable and more cherry-pick-\n friendly to me to keep these in separate commits.\n\n What I've found is I can use a line in the commit message like\n     \"Incomplete change, requires next commit (update foo/ dir).\"\n and, if there is any point, do a no-ff merge past the breakage.\n\n-- \n Hallvard\n"},{"id":"181208","messageId":"20111215104444.783303cf@ashu.dyn1.rarus.ru","threadId":"29169","inReplyTo":"4cfc9cf0515b1bc751f6aa0de4f55e2a@ulrik.uio.no","subject":"Re: How to commit incomplete changes?","fromName":"Alexey Shumkin","fromEmail":"alex.crezoff@gmail.com","sentAt":"2011-12-15T06:44:44Z","receivedAt":"2011-12-15T06:44:44Z","isPatch":false,"sender":{"key":"alex.crezoff@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1183752?v=4"},"body":">  Do people have any feelings or conventions for how and when to\n> publish a series of commits where the first one(s) break something\n> and the next ones clear it up?\nI'm curiuos, why to you want to commit changes that break something\nseparately from fixup?\n\nMany conventions (as I know) use ideology that every commit must NOT\nBREAK existing code or tests. Every SHARED commit. Git design (as you\nmust be already know) allows you to make/change/reorder as many commits\nas you want (before you share them or push to a \"central\" repository).\nSo, you have not to be afraid to commit every your change, because you\ncan always change/fixup/split your commits.\n\nUsually, you introduce a feature in a branch. Also, your project must\nhave (?) (mine do have) unit-tests, at least. And most changes must be\ntested. So, breakage must be discovered early, even after some other\ncommits in that feature branch. In that case you can just make a fixup\ncommit and then rebase it on a breakage commit with a \"squash\".\n\nAnd only after all features made and all tests passed you can share\nthem (push to another repo).\n\n>I've found some discussion, but with vague results.\n> \n>  I'm about to commit some small edits which go together with bigger\n>  generated changes.  It seems both more readable and more cherry-pick-\n>  friendly to me to keep these in separate commits.\n> \n>  What I've found is I can use a line in the commit message like\n>      \"Incomplete change, requires next commit (update foo/ dir).\"\n>  and, if there is any point, do a no-ff merge past the breakage.\n> \n"},{"id":"181211","messageId":"7e1ccfac8c47e8877c0438086bd1d91b@ulrik.uio.no","threadId":"29169","inReplyTo":"20111215104444.783303cf@ashu.dyn1.rarus.ru","subject":"Re: How to commit incomplete changes?","fromName":"Hallvard B Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2011-12-15T07:11:38Z","receivedAt":"2011-12-15T07:11:38Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":" On Thu, 15 Dec 2011 10:44:44 +0400, Alexey Shumkin \n <Alex.Crezoff@gmail.com> wrote:\n>> Do people have any feelings or conventions for how and when to\n>> publish a series of commits where the first one(s) break something\n>> and the next ones clear it up?\n>\n> I'm curiuos, why to you want to commit changes that break something\n> separately from fixup?\n\n I answered that, but maybe too briefly:\n\n>>  I'm about to commit some small edits which go together with bigger\n>>  generated changes.  It seems both more readable and more \n>> cherry-pick-\n>>  friendly to me to keep these in separate commits.\n\n To expand on that: To review the change, review the hand-edited \n commits,\n which is easier when these do not drown in generated changes.  Review\n the *commands* which generated the rest - I'd put those in the commit\n message - and glance at the actual changes.  Cherry-pick: Possbly you\n need to run the commands instead of cherry-picking the generated\n changes.  That's easier with a commit with only generated changes.\n\n I know it also can cause problems.  Would you make a single big commit\n anyway, and describe carefully in the commit message which parts are\n hand-edits?  (We don't auto-test commits yet, but I'll sure this issue\n will crop up again later when we do.)\n\n-- \n Hallvard\n"},{"id":"181216","messageId":"20111215122252.584d1003@ashu.dyn1.rarus.ru","threadId":"29169","inReplyTo":"7e1ccfac8c47e8877c0438086bd1d91b@ulrik.uio.no","subject":"Re: How to commit incomplete changes?","fromName":"Alexey Shumkin","fromEmail":"alex.crezoff@gmail.com","sentAt":"2011-12-15T08:22:52Z","receivedAt":"2011-12-15T08:22:52Z","isPatch":false,"sender":{"key":"alex.crezoff@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1183752?v=4"},"body":"Oh! I got it. I missed \"generated changes\".\nWell, unfortunately (or fortunately ;) ), I did not meet such a workflow\nwhen changes are \"generated\" without my hands.\nIn your case it may sound reasonable to make separate fixup commit.\nBut Git allows you to make your own (more flexible than SVN,\nfor instance) workflow, which suits you. It's up to you ;)\nYou decide.\nIf you plan cherry-picking that fixups, do separate fixups. Just\npublish them together.\nIf you want every commit is \"clear\" and \"workable\", squash fixup into\na single commit.\nI do not know what exactly is \"generated changes\" you're talking\nabout ), so, maybe I'd do separate fixups, maybe not. ))\nThere is no single solution. ))) TIMTOWTDI\nThat is why you hesitate :) Do your own decision. And feel free to\nchange it later. ))\n\n>  To expand on that: To review the change, review the hand-edited \n>  commits,\n>  which is easier when these do not drown in generated changes.  Review\n>  the *commands* which generated the rest - I'd put those in the commit\n>  message - and glance at the actual changes.  Cherry-pick: Possbly you\n>  need to run the commands instead of cherry-picking the generated\n>  changes.  That's easier with a commit with only generated changes.\n> \n>  I know it also can cause problems.  Would you make a single big\n> commit anyway, and describe carefully in the commit message which\n> parts are hand-edits?  (We don't auto-test commits yet, but I'll sure\n> this issue will crop up again later when we do.)\n> \n"},{"id":"181218","messageId":"20111215123907.51b2dc69@ashu.dyn1.rarus.ru","threadId":"29169","inReplyTo":"20111215122252.584d1003@ashu.dyn1.rarus.ru","subject":"Re: How to commit incomplete changes?","fromName":"Alexey Shumkin","fromEmail":"alex.crezoff@gmail.com","sentAt":"2011-12-15T08:39:07Z","receivedAt":"2011-12-15T08:39:07Z","isPatch":false,"sender":{"key":"alex.crezoff@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1183752?v=4"},"body":"> Do your own decision. \n* \"Make your own decision\", of course :)\n"},{"id":"181269","messageId":"4EEA79E0.4070700@gmail.com","threadId":"29169","inReplyTo":"4cfc9cf0515b1bc751f6aa0de4f55e2a@ulrik.uio.no","subject":"Re: How to commit incomplete changes?","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2011-12-15T22:51:12Z","receivedAt":"2011-12-15T22:51:12Z","isPatch":false,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 12/14/2011 5:24 PM, Hallvard B Furuseth wrote:\n> Do people have any feelings or conventions for how and when to publish\n> a series of commits where the first one(s) break something and the next\n> ones clear it up? I've found some discussion, but with vague results.\n>\n> I'm about to commit some small edits which go together with bigger\n> generated changes. It seems both more readable and more cherry-pick-\n> friendly to me to keep these in separate commits.\n>\n> What I've found is I can use a line in the commit message like\n> \"Incomplete change, requires next commit (update foo/ dir).\"\n> and, if there is any point, do a no-ff merge past the breakage.\n>\nA main purpose for the squash and fixup options is (as Randall Schwartz \nput it in his git video http://www.youtube.com/watch?v=8dhZ9BXQgc4) \"To \nmake it look like you did it all perfectly without making any mistakes\" \n(or a reasonable facsimile thereof).  You insights on the cherry-picking \nof fixes is interesting, but makes no sense in the context of \nunpublished work.  Why would you need to cherry-pick fixes to mistakes \nthat have not yet been propagated (published)?  If the cherry-picks of \nfixes are for your other already merged local branches then just save \nthe pre-squash/fixup version of the branch to another branch, (ie, git \nbranch mybranch-b4-fixup) and cherry-pick from that unsquashed copy to \npatch up your other unpublished branches.  Keep in mind that cherry-pick \nis not alway the best way to apply fixes.  A merge or rebase to get the \nfix is the sign of a better workflow in many cases, TBOMK. On the other \nhand, if the bugs have been published then you have no choice but to \ncommit the fix separately because you can't rearrage/edit published \nhistory.  Keep in mind that ideally commits should be logical.  You can \nuse the rearrage feature of interactive rebase to squash fixes into the \nfeature commit they go to. IOW, I don't think squashing everything into \na giant commit just to consolidate bugfixes into a single commit makes \nsense if that would mean losing the distinct separation between \ndiffering feature commits.\n\nI assume by 'generated changes' you mean the automerge in git that is a \nwonderful default for vast systems like the linux kernel in which code \nis unlikely to overlap logically, but very dangerous in legacy \napplication systems where changes to the same file can create logical \nbugs despite not being on the 'exact same line of code'.  You are \nsupposed to review all your merged files after a merge regardless. \nHowever, we don't trust ourselves that much in our shop so we force \nconflicts on same-file edits by making \"user-date stamp\" updates on \n\"line 1\" (depends on language-dependent comment line rules) in our \npre-commit hook.  That way we are forced to manually review the merge of \nsame-file edits \"by hand\" thus avoiding \"generated results\".  Of course, \nunique-file edits can still break things and thus a merge review is \nstill in order.\n\nHope this helps.  I'm not a git workflow expert, but my comments are \nbased on experience.  I too am still looking for better ways to manage \nworkflow while leveraging the flexibity and agility of git for \nconcurrent development.\n\nv/r,\nneal\n"},{"id":"181278","messageId":"7v8vmdl62s.fsf@alter.siamese.dyndns.org","threadId":"29169","inReplyTo":"4EEA79E0.4070700@gmail.com","subject":"Re: How to commit incomplete changes?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-12-16T00:21:15Z","receivedAt":"2011-12-16T00:21:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Neal Kreitzinger <nkreitzinger@gmail.com> writes:\n\n> A main purpose for the squash and fixup options is ...\n> \"To make it look like you\n> did it all perfectly without making any mistakes\" (or a reasonable\n> facsimile thereof).  You insights on the cherry-picking of fixes is\n> interesting, but makes no sense in the context of unpublished work.\n> Why would you need to cherry-pick fixes to mistakes that have not yet\n> been propagated (published)?\n> ...\n> I assume by 'generated changes' you mean the automerge in git...\n\nMy reading of the \"need to split\" example was not \"bulk of work plus fixes\nto mistakes\". Imagine you are working on somebody else's code and for some\nreason you want to do\n\n\ts/setenv/xsetenv/g\n\nall over the code, and also add a wrapper to implement xsetenv() function.\n\nYou _could_ do it in one single commit, but what happens when you try to\nadjust to the updated upstream code, which may have added new callsites to\nsetenv()?\n\nIf you keep it as two patches, one is mechanical (i.e. s/setenv/xsetenv/g)\nand the other is manual (i.e. implementation of xsetenv()), then you can\ndiscard the text of the \"mechanical\" one from the old series and instead\nrun the substitution on the updated code, and then cherry-pick the\n\"manual\" one.\n\nIf you did the mechanical one first, the resulting code would not compile\n(lacks xsetenv() implementation), and then the second \"manual\" one would\n\"fix\" it. In this simplified example, it is easy to flip the orders and\nkeep things work, but then you would get a complaint from clever compiler\nor linker that xsetenv() implementation is defined but nobody uses it,\nwhich is another kind of breakage. So it _is_ possible that you cannot\navoid breaking the system inside two patches, making them \"all-or-none\"\nseries.\n"},{"id":"181279","messageId":"4EEAA3C5.2070907@dbservice.com","threadId":"29169","inReplyTo":"4cfc9cf0515b1bc751f6aa0de4f55e2a@ulrik.uio.no","subject":"Re: How to commit incomplete changes?","fromName":"Tomas Carnecky","fromEmail":"tom@dbservice.com","sentAt":"2011-12-16T01:49:57Z","receivedAt":"2011-12-16T01:49:57Z","isPatch":false,"sender":{"key":"tom@dbservice.com","avatar":"https://gravatar.com/avatar/900a300bdd1a8bbe086008ad78210bbee2ad2803b7d50a5cba04c1e9404bd6d2?d=mp&s=160"},"body":"On 12/15/11 12:24 AM, Hallvard B Furuseth wrote:\n> I'm about to commit some small edits which go together with bigger\n> generated changes.  It seems both more readable and more cherry-pick-\n> friendly to me to keep these in separate commits.\nWhy do you store generated code? Usually you only store what is \nabsolutely necessary. That means generated code should be generated as \nneeded (part of the build process for example).\n\ntom\n"},{"id":"181291","messageId":"hbf.20111216xubv@bombur.uio.no","threadId":"29169","inReplyTo":"7v8vmdl62s.fsf@alter.siamese.dyndns.org","subject":"Re: How to commit incomplete changes?","fromName":"Hallvard Breien Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2011-12-16T12:15:28Z","receivedAt":"2011-12-16T12:15:28Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":"[Neal Kreitzinger]\n> I assume by 'generated changes' you mean the automerge in git...\n\nNo.  And to your questions of why I want this with unpublished work:\nNo.  Like I wrote, I'm talking about published commits.\n\n[Junio C Hamano]\n> My reading of the \"need to split\" example was not \"bulk of work plus fixes\n> to mistakes\".  Imagine you are working on somebody else's code and for some\n> reason you want to do\n> \n> \ts/setenv/xsetenv/g\n> \n> all over the code, and also add a wrapper to implement xsetenv() function.\n\nYes - except there is no \"mistakes\" since it's deliberate.  I'd do\ns/setenv/xsetenv/g, which does too little (misses some preprocessor\nstuff) or is too greedy, then commit anyway and clean up in next commit.\n\nI could make and commit a much more complicated script to do it all, but\nthat's unhelpful when trying to read what the heck the change is doing.\nAnd who knows what it'd do when run on a somewhat different codebase.\n\nThat example matches a future internal API change.  My current issue\nis changes generated with 'autoreconf' - after cleaning up an utter\nlibtool/automake mess by hand, which will break things if I don't\nautoreconf in the same commmit.\n\n> You _could_ do it in one single commit, but what happens when you try to\n> adjust to the updated upstream code, which may have added new callsites to\n> setenv()?\n\nIndeed.  In this case, it'd be when cherry-picking from the devel branch\nto the release branch.  These still differ too much, a legacy of our old\nCVS workflow.\n\n> If you keep it as two patches, one is mechanical (i.e. s/setenv/xsetenv/g)\n> and the other is manual (i.e. implementation of xsetenv()), then you can\n> discard the text of the \"mechanical\" one from the old series and instead\n> run the substitution on the updated code, and then cherry-pick the\n> \"manual\" one.\n\nYes.  I'd order it in a sequence which never broke anything if I could.\n\nWell, come to think of it: Possibly I could introduce some new code\nwhich would only exist for the sake of patching over the temporary\nbreakage, and then delete that code again 2-3 commits later.  In this\ncase, I'd among other things create an obsolete libtool.m4 which is\ncurrently hiding inside aclocal.m4.  Not sure if that makes more sense\nthan just having a few broken commits.\n\n-- \nHallvard\n"},{"id":"181292","messageId":"hbf.20111216ym10@bombur.uio.no","threadId":"29169","inReplyTo":"hbf.20111216xubv@bombur.uio.no","subject":"Re: How to commit incomplete changes?","fromName":"Hallvard Breien Furuseth","fromEmail":"h.b.furuseth@usit.uio.no","sentAt":"2011-12-16T12:58:12Z","receivedAt":"2011-12-16T12:58:12Z","isPatch":false,"sender":{"key":"h.b.furuseth@usit.uio.no","avatar":null},"body":"I wrote:\n>[Neal Kreitzinger]\n>> I assume by 'generated changes' you mean the automerge in git...\n> \n> No.  And to your questions of why I want this with unpublished work:\n> No.  Like I wrote, I'm talking about published commits.\n\nWait, I see - as-yet unpublished commits, yes.  Which seem best to me to\npublish that way.  And which will get cherry-picked later, after commit\nand testing.\n\n-- \nHallvard\n"}]}