{"thread":{"id":"6635","subject":"Why is it bad to rewind a branch that has already been pushed out?","startedAt":"2007-02-03T06:40:49Z","lastAt":"2007-02-06T14:47:49Z","messageCount":12,"participants":["Junio C Hamano","Andy Parkins","Theodore Tso","Robin Rosenberg","Michael","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"33434","messageId":"7v1wl7bv66.fsf@assigned-by-dhcp.cox.net","threadId":"6635","inReplyTo":null,"subject":"Why is it bad to rewind a branch that has already been pushed out?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-03T06:40:49Z","receivedAt":"2007-02-03T06:40:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I was reading the tutorial and noticed that we say this:\n\n Also, don't use \"git reset\" on a publicly-visible branch that\n other developers pull from, as git will be confused by history\n that disappears in this way.\n\nI do not think this is a good explanation. For example, if we\ndo this:\n\n(1) I build a series and push it out.\n\n\t---o---o---o---j\n\n(2) Alice clones from me, and builds two commits on top of it.\n\n\t---o---o---o---j---a---a\n\n(3) I rewind one and build a few, and push them out.\n\n\t---o---o---o...j\n \\\n h---h---h---h\n\n(4) Alice pulls from me again:\n\n\t---o---o---o---j---a---a---*\n \\ /\n h---h---h---h\n\nContrary to the description, git will happily have Alice merge\nbetween the two branches, and never gets confused.\n\nMaybe I did not want to have 'j' because it was an incomplete\nsolution to some problem, and Alice may have fixed it up with\nher changes, while I abandoned that approach I started with 'j',\nand worked on something completely unrelated in the four 'h'\ncommits. In such a case, the merge Alice would make would be\nvery sensible, and after she makes the merge if I pull from her,\nthe world will be perfect. I started something with 'j' and\ndropped the ball, Alice picked it up and perfected it while I\nwent on to work on something else with 'h'. This would be a\nperfect example of distributed parallel collaboration. There is\nnothing confused about it.\n\nThe case the rewinding becomes problematic is if the work done\nin 'h' tries to solve the same problem as 'j' tried to solve in\na different way. Then the merge forced on Alice would make her\npick between my previous attempt with her fixups (j+a) and my\nsecond attempt (h). If 'a' commits were to fix up what 'j'\nstarted, presumably Alice already studied and knows enough about\nthe problem so she should be able to make an informed decision\nto pick between what 'j+a' and 'h' do.\n\nA lot worse case is if Alice's work is not at all related to\nwhat 'j' wanted to do (she did not mean to pick up from where I\nleft off -- she just wanted to work on something different).\nThen she would not be familiar enough with what 'j' and 'h'\ntried to achieve, and I'd be forcing her to pick between the\ntwo. Of course if she can make the right decision, then again\nthat is a perfect example of distributed collaboration, but that\ndoes not change the fact that I'd be forcing her to clean up my\nmess.\n\nSo I am thinking about rewording the section like this.\n\nComments?\n\n---\n\ndiff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\nindex ea34189..5fc5be5 100644\n--- a/Documentation/tutorial.txt\n+++ b/Documentation/tutorial.txt\n@@ -458,9 +458,9 @@ $ git reset --hard HEAD^ # reset your current branch and working\n Be careful with that last command: in addition to losing any changes\n in the working directory, it will also remove all later commits from\n this branch. If this branch is the only branch containing those\n-commits, they will be lost. (Also, don't use \"git reset\" on a\n-publicly-visible branch that other developers pull from, as git will\n-be confused by history that disappears in this way.)\n+commits, they will be lost. Also, don't use \"git reset\" on a\n+publicly-visible branch that other developers pull from, as it will\n+force needless merges on other developers to clean up the history.\n \n The git grep command can search for strings in any version of your\n project, so\n"},{"id":"33443","messageId":"200702031041.13437.andyparkins@gmail.com","threadId":"6635","inReplyTo":"7v1wl7bv66.fsf@assigned-by-dhcp.cox.net","subject":"Re: Why is it bad to rewind a branch that has already been pushed out?","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-03T10:40:54Z","receivedAt":"2007-02-03T10:40:54Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Saturday 2007, February 03 06:40, Junio C Hamano wrote:\n\n> Also, don't use \"git reset\" on a publicly-visible branch that\n> other developers pull from, as git will be confused by history\n> that disappears in this way.\n>\n> I do not think this is a good explanation. For example, if we\n> do this:\n\nI agree it's not a good explanation, I think it is good policy though. \nI love an oppourtunity to blather on and your post has given it to \nme :-) I'm sure I'll be preaching to the converted though.\n\nIn the following I've assumed that both \"h\" and \"a\" commits are \nindependent work, neither of which works on \"j\" (which isn't quite what \nyou described). It's not really appropriate for the tutorial, so I \nhaven't really helped you.\n\n-----------------\ngit's easy manipulation of branches encourages one to try to make \nhistory really tell the story of development. It's more than just \nrecording snapshots, there is information in the history itself - \nreasons for decisions can be recorded - separating and collecting \ncommits into appropriate branches instead of one giant linear block.\n\nAs you say git is perfectly okay with the rewound branch and will do the \nRight Thing to preserve the changes. However, it won't get the spirit \nof the changes right.\n\n> (4) Alice pulls from me again:\n>\n> \t---o---o---o---j---a---a---*\n> \\ /\n> h---h---h---h\n>\n> Contrary to the description, git will happily have Alice merge\n> between the two branches, and never gets confused.\n\nThe problem is not that the working tree is wrong, it is that the \nhistory is wrong. This sequence of development isn't best represented \nby a merge. When we look at the history later, we'll see it as two \nbranches, but that isn't true.\n\nThe graph shows that \"j\" was committed and then probably conflicted \nin \"*\" and fixed. The problem is that you can't point to any non-merge \ncommit that reverted/corrected \"j\" and explains why that wasn't a good \nidea - so the \"story\" that the history tells us is incomplete. The \ncorrection was done just as a conflict resolution in \"*\".\n\nAny of these would be correct:\n\n1) \"h\" and \"a\" are parallel; \"j\" never happens\n\n ---o---o---o----a-----a----*\n \\ /\n h---h---h---h\n\n2) Alice corrects \"j\" with a \"!j\" revision - \"!j\" would then describe \nwhy \"j\" was wrong and what the fix was. \"h\" would have to have nothing \nto do with the \"j\" topic in this case.\n\n ---o---o---o---j---!j---a---a---*\n \\ /\n h-----h-----h----h\n\nOf course, both of these require information from the developer. (1) \ncan't be done after the push has been done (because \"j\" is already \"out \nthere\") and (2) requires that \"h\" know that Alice has fixed the problem \nand the Alice knows that the \"j\" problem needs fixing (and probably \ndoesn't belong in Alice's branch anyway).\n\nThe only solution that keeps the history integrity, is the one that all \nthe git manuals reccommend.\n\n3) Don't rebase at all, correct the problem and record the correction.\n\n --o---o---o---j------a------a------*\n \\ /\n !j---h---h---h---h\n\nThat is - once a mistaken commit has been pushed out, it's there \nforever, accept that and don't rebase to before the last push. \nSometimes it makes the history less pretty, but it makes it more right. \nWithout \"!j\", no one would ever know what was wrong with \"j\".\n\nIn short - heed the warnings - you will get much better history if you \ndon't rebase branches that have already been pushed upstream.\n-----------------------\n\nHow about that as the explanation for the tutorial? What do you mean I \nhaven't simplified anything and have replaced one paragraph with a page \nworth of overly wordy ravings? HOW DARE YOU! :-)\n\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\nandyparkins@gmail.com\n"},{"id":"33445","messageId":"20070203132059.GB15419@thunk.org","threadId":"6635","inReplyTo":"7v1wl7bv66.fsf@assigned-by-dhcp.cox.net","subject":"Re: Why is it bad to rewind a branch that has already been pushed out?","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-02-03T13:20:59Z","receivedAt":"2007-02-03T13:20:59Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Fri, Feb 02, 2007 at 10:40:49PM -0800, Junio C Hamano wrote:\n> I do not think this is a good explanation. For example, if we\n> do this:\n> \n> (1) I build a series and push it out.\n> \n> \t---o---o---o---j\n> \n> (2) Alice clones from me, and builds two commits on top of it.\n> \n> \t---o---o---o---j---a---a\n> \n> (3) I rewind one and build a few, and push them out.\n> \n> \t---o---o---o...j\n> \\\n> h---h---h---h\n> \n> (4) Alice pulls from me again:\n> \n> \t---o---o---o---j---a---a---*\n> \\ /\n> h---h---h---h\n> \n> Contrary to the description, git will happily have Alice merge\n> between the two branches, and never gets confused.\n> \n> Maybe I did not want to have 'j' because it was an incomplete\n> solution to some problem....\n\nAnother scenario might be if 'j' was just a bad idea, and should have\nnever been committed in the first place. Now if Alice builds upon it,\nand at some later point Alice asks you to pull from her repository,\n'j' will appear back in your repository. So it's better to have a\nchangeset which simply undoes 'j' rathern than rewind, once you've\npushed out the repository.\n\nThe one exception to this is if 'j' contains something which might be\nproblematic from a copyright point of view, in which case you're\nlargely screwed if other people such as Alice has already pulled from\nyou and started basing changes on 'j'.\n\n\t\t\t\t\t\t\t- Ted\n"},{"id":"33469","messageId":"7vy7nf3u5m.fsf@assigned-by-dhcp.cox.net","threadId":"6635","inReplyTo":"200702031041.13437.andyparkins@gmail.com","subject":"Re: Why is it bad to rewind a branch that has already been pushed out?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-03T19:42:13Z","receivedAt":"2007-02-03T19:42:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> In the following I've assumed that both \"h\" and \"a\" commits are \n> independent work, neither of which works on \"j\" (which isn't quite what \n> you described). It's not really appropriate for the tutorial, so I \n> haven't really helped you.\n> ...\n>> (4) Alice pulls from me again:\n>>\n>> \t---o---o---o---j---a---a---*\n>> \\ /\n>> h---h---h---h\n>>\n>> Contrary to the description, git will happily have Alice merge\n>> between the two branches, and never gets confused.\n>\n> The problem is not that the working tree is wrong, it is that the \n> history is wrong. This sequence of development isn't best represented \n> by a merge. When we look at the history later, we'll see it as two \n> branches, but that isn't true.\n>\n> The graph shows that \"j\" was committed and then probably conflicted \n> in \"*\" and fixed. The problem is that you can't point to any non-merge \n> commit that reverted/corrected \"j\" and explains why that wasn't a good \n> idea - so the \"story\" that the history tells us is incomplete. The \n> correction was done just as a conflict resolution in \"*\".\n\nActually, if you are assuming a, h, and j are unrelated, then\nthe merge done by Alice will _not_ revert 'j', so the history\nwill perfectly be fine. The merge result will have a half-baked\nwork done with 'j', and everybody can build on top of.\n"},{"id":"33575","messageId":"200702041716.39999.robin.rosenberg.lists@dewire.com","threadId":"6635","inReplyTo":"7v1wl7bv66.fsf@assigned-by-dhcp.cox.net","subject":"Re: Why is it bad to rewind a branch that has already been pushed out?","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-02-04T16:16:39Z","receivedAt":"2007-02-04T16:16:39Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Mention git-revert as an alternative to git-reset to revert changes.\n\nSigned-off-by: Robin Rosenberg \n---\n\ndiff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\nindex 5fc5be5..129c5c5 100644\n--- a/Documentation/tutorial.txt\n+++ b/Documentation/tutorial.txt\n@@ -461,6 +461,8 @@ this branch. If this branch is the only branch containing \nthose\n commits, they will be lost. Also, don't use \"git reset\" on a\n publicly-visible branch that other developers pull from, as it will\n force needless merges on other developers to clean up the history.\n+If you need to undo changes that you have pushed, use gitlink:git-revert[1]\n+instead.\n\n The git grep command can search for strings in any version of your\n project, so\n"},{"id":"33579","messageId":"200702041801.31110.andyparkins@gmail.com","threadId":"6635","inReplyTo":"7vy7nf3u5m.fsf@assigned-by-dhcp.cox.net","subject":"Re: Why is it bad to rewind a branch that has already been pushed out?","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-04T18:01:29Z","receivedAt":"2007-02-04T18:01:29Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Saturday 2007, February 03 19:42, Junio C Hamano wrote:\n\n> Actually, if you are assuming a, h, and j are unrelated, then\n> the merge done by Alice will _not_ revert 'j', so the history\n> will perfectly be fine. The merge result will have a half-baked\n> work done with 'j', and everybody can build on top of.\n\nAbsolutely true.\n\nYour point is a strong one. I think I'm still not thinking big enough \nwith the distributed development concept. Your point has made me \nconsider that I've been overly concerned about not rebasing pushed \ncommits. Provided you're willing to correct conflicts in a merge; they \naren't as bad as I initially thought - in fact they offer a further \nchoice when creating project history.\n\nThanks Junio.\n\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\nandyparkins@gmail.com\n"},{"id":"33586","messageId":"7vlkjdr8hj.fsf@assigned-by-dhcp.cox.net","threadId":"6635","inReplyTo":"200702041716.39999.robin.rosenberg.lists@dewire.com","subject":"Re: Why is it bad to rewind a branch that has already been pushed out?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-04T20:08:40Z","receivedAt":"2007-02-04T20:08:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robin Rosenberg writes:\n\n> Mention git-revert as an alternative to git-reset to revert changes.\n\nThanks; that makes sense. Applied.\n\nIt is not a biggie but for future reference you might want to\ncheck your KMail configuration to avoid the wrapped line below:\n\n> diff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\n> index 5fc5be5..129c5c5 100644\n> --- a/Documentation/tutorial.txt\n> +++ b/Documentation/tutorial.txt\n> @@ -461,6 +461,8 @@ this branch. If this branch is the only branch containing \n> those\n> commits, they will be lost. Also, don't use \"git reset\" on a\n"},{"id":"33633","messageId":"200702051427.32532.barra_cuda@katamail.com","threadId":"6635","inReplyTo":"7vlkjdr8hj.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Documentation: add KMail in SubmittingPatches","fromName":"Michael","fromEmail":"barra_cuda@katamail.com","sentAt":"2007-02-05T13:27:32Z","receivedAt":"2007-02-05T13:27:32Z","isPatch":true,"sender":{"key":"barra_cuda@katamail.com","avatar":"https://avatars.githubusercontent.com/u/16371673?v=4"},"body":"\nSigned-off-by: Michael \n---\n Documentation/SubmittingPatches | 19 ++++++++++++++++++-\n 1 files changed, 18 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches\nindex ce85d06..a3dafa5 100644\n--- a/Documentation/SubmittingPatches\n+++ b/Documentation/SubmittingPatches\n@@ -316,7 +316,6 @@ settings but I haven't tried, yet.\n \tmail.identity.id?.compose_html\t\t=> false\n \n \n-\n Gnus\n ----\n \n@@ -331,3 +330,21 @@ whitespaces (fatal in patches). Running 'C-u g' to \ndisplay the\n message in raw form before using '|' to run the pipe can work\n this problem around.\n \n+\n+KMail\n+-----\n+\n+This should help you to submit patches inline using KMail.\n+\n+1) Prepare the patch as a text file.\n+\n+2) Click on New Mail.\n+\n+3) Go under \"Options\" in the Composer window and be sure that\n+\"Word wrap\" is not set.\n+\n+4) Use Message -> Insert file... and insert the patch.\n+\n+5) Back in the compose window: add whatever other text you wish to the\n+message, complete the addressing and subject fields, and press send.\n+\n-- \n1.4.4.2\n"},{"id":"33686","messageId":"7vveigkmpv.fsf@assigned-by-dhcp.cox.net","threadId":"6635","inReplyTo":"200702051427.32532.barra_cuda@katamail.com","subject":"Re: [PATCH] Documentation: add KMail in SubmittingPatches","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-06T03:07:40Z","receivedAt":"2007-02-06T03:07:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael writes:\n\n> @@ -331,3 +330,21 @@ whitespaces (fatal in patches). Running 'C-u g' to \n> display the\n> message in raw form before using '|' to run the pipe can work\n> this problem around.\n> \n> +\n> +KMail\n> +-----\n> +\n> +This should help you to submit patches inline using KMail.\n> +\n> +1) Prepare the patch as a text file.\n> +\n> +2) Click on New Mail.\n> +\n> +3) Go under \"Options\" in the Composer window and be sure that\n> +\"Word wrap\" is not set.\n> +\n> +4) Use Message -> Insert file... and insert the patch.\n> +\n> +5) Back in the compose window: add whatever other text you wish to the\n> +message, complete the addressing and subject fields, and press send.\n> +\n\nThis is quite interesting -- notice your own hunk header @@ ... @@ line?\n\nI do not use KMail myself, so I cannot comment on the procedure,\nbut from the cursory look it *should* do the right thing. Only\nthat it makes me a bit nervous to see your hunk header being\nline wrapped.\n\nDoubly interesting is that somebody appears to have added two\nmessage IDs.\n\n Subject: [PATCH] Documentation: add KMail in SubmittingPatches\n Date:\tMon, 5 Feb 2007 14:27:32 +0100\n User-Agent: KMail/1.9.4\n Message-Id: <200702051427.32532.barra_cuda@katamail.com>\n Message-ID: <20070205132150.123659@dial-up-mi-449.lombardiacom.it>\n"},{"id":"33720","messageId":"200702061445.07657.barra_cuda@katamail.com","threadId":"6635","inReplyTo":"7vveigkmpv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: add KMail in SubmittingPatches","fromName":"Michael","fromEmail":"barra_cuda@katamail.com","sentAt":"2007-02-06T13:45:07Z","receivedAt":"2007-02-06T13:45:07Z","isPatch":true,"sender":{"key":"barra_cuda@katamail.com","avatar":"https://avatars.githubusercontent.com/u/16371673?v=4"},"body":"Junio C Hamano:\n> Michael writes:\n> > @@ -331,3 +330,21 @@ whitespaces (fatal in patches). Running 'C-u g' to\n> > display the\n> > message in raw form before using '|' to run the pipe can work\n> > this problem around.\n[...]\n> This is quite interesting -- notice your own hunk header @@ ... @@ line?\n\nI see. It's this account's fault: now I know because I've tried with\nanother account. I didn't know it had this glitch, sorry.\n\n> I do not use KMail myself, so I cannot comment on the procedure,\n> but from the cursory look it *should* do the right thing. Only\n> that it makes me a bit nervous to see your hunk header being\n> line wrapped.\n>\n> Doubly interesting is that somebody appears to have added two\n> message IDs.\n>\n> Subject: [PATCH] Documentation: add KMail in SubmittingPatches\n> Date:\tMon, 5 Feb 2007 14:27:32 +0100\n> User-Agent: KMail/1.9.4\n> Message-Id: <200702051427.32532.barra_cuda@katamail.com>\n> Message-ID: <20070205132150.123659@dial-up-mi-449.lombardiacom.it>\n\nThis is my current account's fault too. So I used KMail correctly,\nbut my mail server did something to the message. I guess I should\nuse another account. Anyway, if some other KMail user has something\nto say about this issue, it will make things clearer.\n\nBye.\n"},{"id":"33723","messageId":"eqa2hs$lmu$1@sea.gmane.org","threadId":"6635","inReplyTo":"200702061445.07657.barra_cuda@katamail.com","subject":"Re: [PATCH] Documentation: add KMail in SubmittingPatches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-06T14:16:57Z","receivedAt":"2007-02-06T14:16:57Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Michael wrote:\n\n> This is my current account's fault too. So I used KMail correctly,\n> but my mail server did something to the message. I guess I should\n> use another account. Anyway, if some other KMail user has something\n> to say about this issue, it will make things clearer.\n\nI have send patches succesfully via KMail, using described procedure\n(Options > Word wrap, Message > Insert File, move subject line to\nSubject field, remove email headers unless with different From,...).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33725","messageId":"200702061447.51459.andyparkins@gmail.com","threadId":"6635","inReplyTo":"7vveigkmpv.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Documentation: add KMail in SubmittingPatches","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-06T14:47:49Z","receivedAt":"2007-02-06T14:47:49Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 February 06 03:07, Junio C Hamano wrote:\n\n> I do not use KMail myself, so I cannot comment on the procedure,\n> but from the cursory look it *should* do the right thing. Only\n> that it makes me a bit nervous to see your hunk header being\n> line wrapped.\n\nI use Kmail for submitting patches, and it seems to work okay. The important \nthing is to turn word wrap off as soon as you open it. If you did this:\n\n * Save patch as draft (say with git-imap-send)\n * Open draft\n * Close draft\n * Open draft\n * Turn word wrap off\n * Send\n\nYou would have a badly wrapped patch. The reason is that until you store the \nemail again, kmail seems to know the difference between a hard LF that was in \nthe original email and a LF that it inserted to wrap the lines. So, as soon \nas you turn word wrap off all the soft LFs go away - perfect. However, if \nyou save without turning word wrap off, all those soft LFs become hard and \nthe next time you open the email there is no easy way to get the untouched \nemail back.\n\nMichael's original instructions seem fine though. I don't think his word wrap \nproblem in this case is the work of KMail.\n\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"}]}