{"thread":{"id":"14316","subject":"[FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","startedAt":"2008-07-06T21:22:50Z","lastAt":"2008-07-08T19:28:22Z","messageCount":28,"participants":["Brian Gernhardt","Junio C Hamano","Mike Hommey","Nanako Shiraishi","Theodore Tso","Jakub Narebski","Jay Soffian","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"82396","messageId":"1215379370-34265-1-git-send-email-benji@silverinsanity.com","threadId":"14316","inReplyTo":null,"subject":"[FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-07-06T21:22:50Z","receivedAt":"2008-07-06T21:22:50Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"This makes rebase act a little more like merge when working on the\ncurrent branch. This is particularly useful for `git pull --rebase`\n\nSigned-off-by: Brian Gernhardt \n---\n\n ARG! This is what v3 was supposed to be. I should make sure I am sending in\n the correct patch. (Tip: run format-patch again after a commit --amend.) Bad\n weekend for me, apparently trying to do too many things at once. Sorry for\n all the noise.\n\n To recap:\n\n If I followed the discussion correctly the first time I sent in this patch,\n the two issues were:\n\n - Ugly \"echo > ORIG_HEAD\" instead of pretty \"git update-ref ORIG_HEAD\"\n - Setting ORIG_HEAD at the wrong place\n\n This version (as opposed to v2, or the embarrassingly identital \"v3\") uses\n the correct variable. $orig_head looks like the right name, but it stores the\n branch. $prev_head stores the actual SHA1, which is what I was looking for.\n\n git-rebase.sh | 1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex e2d85ee..1048f7e 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -434,3 +434,4 @@ do\n done\n \n finish_rb_merge\n+git update-ref ORIG_HEAD $prev_head\n-- \n1.5.6.2.348.gcff8f.dirty\n"},{"id":"82413","messageId":"7v7iby9ucx.fsf@gitster.siamese.dyndns.org","threadId":"14316","inReplyTo":"1215379370-34265-1-git-send-email-benji@silverinsanity.com","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-07T04:43:58Z","receivedAt":"2008-07-07T04:43:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brian Gernhardt writes:\n\n> This makes rebase act a little more like merge when working on the\n> current branch. This is particularly useful for `git pull --rebase`\n>\n> Signed-off-by: Brian Gernhardt \n> ---\n>\n> ARG! This is what v3 was supposed to be. I should make sure I am sending in\n> the correct patch.\n\nYeah, I was scratching my head about the discrepancy between the revision\ncomment and the patch in the previous one.\n\nHaving said that, thanks to updates to git-rebase, rebased_branch@{1} has\nuseful information these days, so I do not see much practical upside, even\nthough I _will_ apply this patch, just for the sake of consistency.\n\nWe would make it _appear_ rebase and merge are interchangeable even more.\nBut the thing is, I am not convinced if promoting that appearance is\nnecessarily a good thing.\n\nYou now do not have to say something like:\n\n\tAfter a 'git pull' you can view 'git diff ORIG_HEAD..' to check\n\twhat are new, but 'git pull --rebase' is different and you would\n\tsay 'git diff branch@{1}..\" instead.\n\nand you can tell the users that ORIG_HEAD can be used in both cases.\n\nBut you cannot say the same thing with \"gitk ORIG_HEAD..\", for example.\nThe meaning of the topology and commits you would see would be quite\ndifferent. For rebase you will see your own commits that are carried\nforward, and for merge you won't. Besides this example, there probably\nare many fundamental differences between rebase and merge, and trying to\ngive a false impression that they are interchangeable may not add much\nvalue to the end user experience, and it could even be harmful from\neducational point of view.\n"},{"id":"82414","messageId":"803A3528-2451-4C5D-A48D-5E0C37B8E90E@silverinsanity.com","threadId":"14316","inReplyTo":"7v7iby9ucx.fsf@gitster.siamese.dyndns.org","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-07-07T05:16:06Z","receivedAt":"2008-07-07T05:16:06Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jul 7, 2008, at 12:43 AM, Junio C Hamano wrote:\n\n> Having said that, thanks to updates to git-rebase, \n> rebased_branch@{1} has\n> useful information these days, so I do not see much practical \n> upside, even\n> though I _will_ apply this patch, just for the sake of consistency.\n\nI've been running rebase a lot over the last few days, and my \nimpression was that git-rebase adds an entry to ther eflog for each \npatch it runs over. While this has its uses, it makes HEAD@{1} not \nterribly useful after a \"pull --rebase\". Of course, it took me three \ntries to get a one-line patch out this weekend, so my judgement is \nobviously not that great at the moment.\n\nI do appreciate that you'll apply it though. As useful as I find \nrebasing pull useful, I dislike maintaining patches on top of git. It \ntends to lead to something breaking when I don't have time to fix \nit. ;-)\n\n> We would make it _appear_ rebase and merge are interchangeable even \n> more.\n> But the thing is, I am not convinced if promoting that appearance is\n> necessarily a good thing.\n\nI don't really think promoting it is a good idea, actually. I do, \nhowever, think that having ORIG_HEAD set intelligently after a pull \nis. I nearly added setting ORIG_HEAD to pull, but didn't think that \nremoving it from merge or setting it twice was a good plan.\n\nBesides, I've done the wrong rebase more than once and having the \nquick recovery is excellent. (Reflogs are great, but when the commit \nmessages are identical it becomes a little difficult to figure out \nwhich one to use.)\n\n> But you cannot say the same thing with \"gitk ORIG_HEAD..\", for \n> example.\n> The meaning of the topology and commits you would see would be quite\n> different. For rebase you will see your own commits that are carried\n> forward, and for merge you won't. Besides this example, there \n> probably\n> are many fundamental differences between rebase and merge, and \n> trying to\n> give a false impression that they are interchangeable may not add much\n> value to the end user experience, and it could even be harmful from\n> educational point of view.\n\nHowever, the rebased patches may have changed in subtle ways, so \nhaving them appear in gitk is a good thing. If I was trying to teach \nsomeone git, I'd compare the rebased commits to the merge commit. \nThey both give information on how any conflicts were resolved \n(although the information is more subtle with rebase).\n\nMy final thought is that the rational ORIG_HEAD and when we set it is \nnot clearly documented anywhere. But I am currently out of time to \nwork on git, so that patch won't be coming from me soon.\n\n~~ Brian\n"},{"id":"82416","messageId":"7vwsjy8dwo.fsf@gitster.siamese.dyndns.org","threadId":"14316","inReplyTo":"803A3528-2451-4C5D-A48D-5E0C37B8E90E@silverinsanity.com","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-07T05:24:39Z","receivedAt":"2008-07-07T05:24:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brian Gernhardt writes:\n\n> On Jul 7, 2008, at 12:43 AM, Junio C Hamano wrote:\n>\n>> Having said that, thanks to updates to git-rebase,\n>> rebased_branch@{1} has\n>> useful information these days, so I do not see much practical\n>> upside, even\n>> though I _will_ apply this patch, just for the sake of consistency.\n>\n> I've been running rebase a lot over the last few days, and my\n> impression was that git-rebase adds an entry to ther eflog for each\n> patch it runs over. While this has its uses, it makes HEAD@{1} not\n> terribly useful after a \"pull --rebase\".\n\nActually, I was not talking about HEAD@{1}. Check the reflog of the\nbranch you rebased, i.e.\n\n\t$ git checkout bg/rebase\n $ git rebase master\n $ git diff bg/rebase@{1} bg/rebase\n\nIf you have two patches in bg/rebase, HEAD@{2} will be the updated master,\nHEAD@{1} will be the first patch on top of it, and HEAD will be the\nrebased tip. bg/rebase@{1} on the other hand is the tip of bg/rebase\nbefore you started rebasing (i.e. the result of \"git checkout bg/rebase\"\nabove).\n"},{"id":"82417","messageId":"20080707054105.GB9737@glandium.org","threadId":"14316","inReplyTo":"7v7iby9ucx.fsf@gitster.siamese.dyndns.org","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-07-07T05:41:05Z","receivedAt":"2008-07-07T05:41:05Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Sun, Jul 06, 2008 at 09:43:58PM -0700, Junio C Hamano wrote:\n> Brian Gernhardt writes:\n> \n> > This makes rebase act a little more like merge when working on the\n> > current branch. This is particularly useful for `git pull --rebase`\n> >\n> > Signed-off-by: Brian Gernhardt \n> > ---\n> >\n> > ARG! This is what v3 was supposed to be. I should make sure I am sending in\n> > the correct patch.\n> \n> Yeah, I was scratching my head about the discrepancy between the revision\n> comment and the patch in the previous one.\n> \n> Having said that, thanks to updates to git-rebase, rebased_branch@{1} has\n> useful information these days, so I do not see much practical upside, even\n> though I _will_ apply this patch, just for the sake of consistency.\n> \n> We would make it _appear_ rebase and merge are interchangeable even more.\n> But the thing is, I am not convinced if promoting that appearance is\n> necessarily a good thing.\n> \n> You now do not have to say something like:\n> \n> \tAfter a 'git pull' you can view 'git diff ORIG_HEAD..' to check\n> \twhat are new, but 'git pull --rebase' is different and you would\n> \tsay 'git diff branch@{1}..\" instead.\n> \n> and you can tell the users that ORIG_HEAD can be used in both cases.\n\nAnd in both cases, you could use HEAD@{1} instead of ORIG_HEAD.\n\nMike\n"},{"id":"82418","messageId":"7vskum8cw9.fsf@gitster.siamese.dyndns.org","threadId":"14316","inReplyTo":"20080707054105.GB9737@glandium.org","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-07T05:46:30Z","receivedAt":"2008-07-07T05:46:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey writes:\n\n> On Sun, Jul 06, 2008 at 09:43:58PM -0700, Junio C Hamano wrote:\n> ...\n>> We would make it _appear_ rebase and merge are interchangeable even more.\n>> But the thing is, I am not convinced if promoting that appearance is\n>> necessarily a good thing.\n>> \n>> You now do not have to say something like:\n>> \n>> \tAfter a 'git pull' you can view 'git diff ORIG_HEAD..' to check\n>> \twhat are new, but 'git pull --rebase' is different and you would\n>> \tsay 'git diff branch@{1}..\" instead.\n>> \n>> and you can tell the users that ORIG_HEAD can be used in both cases.\n>\n> And in both cases, you could use HEAD@{1} instead of ORIG_HEAD.\n\nNo you cannot. Read what I wrote again. I never said HEAD@{1} ;-)\n"},{"id":"82419","messageId":"20080707054816.GA11153@glandium.org","threadId":"14316","inReplyTo":"20080707054105.GB9737@glandium.org","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2008-07-07T05:48:16Z","receivedAt":"2008-07-07T05:48:16Z","isPatch":true,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Mon, Jul 07, 2008 at 07:41:05AM +0200, Mike Hommey wrote:\n> On Sun, Jul 06, 2008 at 09:43:58PM -0700, Junio C Hamano wrote:\n> > Brian Gernhardt writes:\n> > \n> > > This makes rebase act a little more like merge when working on the\n> > > current branch. This is particularly useful for `git pull --rebase`\n> > >\n> > > Signed-off-by: Brian Gernhardt \n> > > ---\n> > >\n> > > ARG! This is what v3 was supposed to be. I should make sure I am sending in\n> > > the correct patch.\n> > \n> > Yeah, I was scratching my head about the discrepancy between the revision\n> > comment and the patch in the previous one.\n> > \n> > Having said that, thanks to updates to git-rebase, rebased_branch@{1} has\n> > useful information these days, so I do not see much practical upside, even\n> > though I _will_ apply this patch, just for the sake of consistency.\n> > \n> > We would make it _appear_ rebase and merge are interchangeable even more.\n> > But the thing is, I am not convinced if promoting that appearance is\n> > necessarily a good thing.\n> > \n> > You now do not have to say something like:\n> > \n> > \tAfter a 'git pull' you can view 'git diff ORIG_HEAD..' to check\n> > \twhat are new, but 'git pull --rebase' is different and you would\n> > \tsay 'git diff branch@{1}..\" instead.\n> > \n> > and you can tell the users that ORIG_HEAD can be used in both cases.\n> \n> And in both cases, you could use HEAD@{1} instead of ORIG_HEAD.\n\nForget it, I just woke up, I'm writing crap.\n\nMike\n"},{"id":"82420","messageId":"20080707151401.6117@nanako3.lavabit.com","threadId":"14316","inReplyTo":"7v7iby9ucx.fsf@gitster.siamese.dyndns.org","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2008-07-07T06:14:01Z","receivedAt":"2008-07-07T06:14:01Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Junio C Hamano :\n\n> Brian Gernhardt writes:\n>\n>> This makes rebase act a little more like merge when working on the\n>> current branch. This is particularly useful for `git pull --rebase`\n>>\n>> Signed-off-by: Brian Gernhardt \n>> ---\n>>\n>> ARG! This is what v3 was supposed to be. I should make sure I am sending in\n>> the correct patch.\n>\n> Yeah, I was scratching my head about the discrepancy between the revision\n> comment and the patch in the previous one.\n>\n> Having said that, thanks to updates to git-rebase, rebased_branch@{1} has\n> useful information these days, so I do not see much practical upside, even\n> though I _will_ apply this patch, just for the sake of consistency.\n\nAre you really aiming for consistency, Junio?\n\nDoesn't this make the behavior of the command inconsistent between \"git-rebase\" and \"git-rebase -m\"?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"82422","messageId":"7vbq1a8ay3.fsf@gitster.siamese.dyndns.org","threadId":"14316","inReplyTo":"803A3528-2451-4C5D-A48D-5E0C37B8E90E@silverinsanity.com","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-07T06:28:36Z","receivedAt":"2008-07-07T06:28:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brian Gernhardt writes:\n\n> My final thought is that the rational ORIG_HEAD and when we set it is\n> not clearly documented anywhere. But I am currently out of time to\n> work on git, so that patch won't be coming from me soon.\n\nThe idea behind ORIG_HEAD is to have an anchoring point before an\noperation that moves your HEAD in a drastic way. Think if it as a\npoor-man's reflog -- in fact it predates reflog.\n\nThat is why reset saves away the HEAD before it does its thing, so that\nyou can easily say \"Oops, I did not mean it -- reset ORIG_HEAD\" to flip\nback to the previous state. Both a fast-forward merge and a real merge\ncan be undone by resetting back to ORIG_HEAD.\n\nSo in that sense:\n\n (1) ORIG_HEAD is not strictly necessary these days, because we have\n reflogs;\n\n (2) Even then, it is handy and useful, and we could add ORIG_HEAD to more\n commands such as \"git am\" and \"git rebase\".\n"},{"id":"82425","messageId":"7vod5a6vgk.fsf@gitster.siamese.dyndns.org","threadId":"14316","inReplyTo":"7vbq1a8ay3.fsf@gitster.siamese.dyndns.org","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-07T06:48:27Z","receivedAt":"2008-07-07T06:48:27Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Brian Gernhardt writes:\n>\n>> My final thought is that the rational ORIG_HEAD and when we set it is\n>> not clearly documented anywhere. But I am currently out of time to\n>> work on git, so that patch won't be coming from me soon.\n>\n> The idea behind ORIG_HEAD is to have an anchoring point before an\n> operation that moves your HEAD in a drastic way. Think if it as a\n> poor-man's reflog -- in fact it predates reflog.\n>\n> That is why reset saves away the HEAD before it does its thing, so that\n> you can easily say \"Oops, I did not mean it -- reset ORIG_HEAD\" to flip\n> back to the previous state. Both a fast-forward merge and a real merge\n> can be undone by resetting back to ORIG_HEAD.\n>\n> So in that sense:\n>\n> (1) ORIG_HEAD is not strictly necessary these days, because we have\n> reflogs;\n>\n> (2) Even then, it is handy and useful, and we could add ORIG_HEAD to more\n> commands such as \"git am\" and \"git rebase\".\n\nPerhaps something like this for \"git am\" (only minimally tested).\n\n-- >8 --\nam: record ORIG_HEAD so that we can quickly undo a large series\n\nThis teaches \"git-am\" to record the commit before it starts its work in\nORIG_HEAD, so that application of a large series can be undone by\nresetting to it.\n\nSigned-off-by: Junio C Hamano \n---\n git-am.sh | 1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/git-am.sh b/git-am.sh\nindex 2c517ed..818b4e5 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -242,6 +242,7 @@ else\n \telse\n \t\t: >\"$dotest/applying\"\n \tfi\n+\tgit update-ref ORIG_HEAD HEAD\n fi\n \n case \"$resolved\" in\n"},{"id":"82428","messageId":"7vvdzi5fl5.fsf@gitster.siamese.dyndns.org","threadId":"14316","inReplyTo":"20080707151401.6117@nanako3.lavabit.com","subject":"Re* [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-07T07:16:38Z","receivedAt":"2008-07-07T07:16:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n> Quoting Junio C Hamano :\n> ...\n>> Having said that, thanks to updates to git-rebase, rebased_branch@{1} has\n>> useful information these days, so I do not see much practical upside, even\n>> though I _will_ apply this patch, just for the sake of consistency.\n>\n> Are you really aiming for consistency, Junio?\n>\n> Doesn't this make the behavior of the command inconsistent between\n> \"git-rebase\" and \"git-rebase -m\"?\n\nHmm, it makes \"rebase -i\" different, too. Luckily, I haven't pushed\nanything out, so I can rewind and all I lose is just a few dozens of\nminutes.\n\nThe one from Brian has another serious issue. That patch does not allow\nyou to refer to ORIG_HEAD during conflict resolution, which is quite\ndifferent from how \"merge\" lets you use ORIG_HEAD. We need to set\nORIG_HEAD upfront if we want to tell user that ORIG_HEAD can be reliably\nused across workflows the same way to name where we were before.\n\nWhen we correctly update \"rebase\" to do this, because one codepath of it\nuses \"am\" as its backend, we cannot use the patch I sent out earlier. We\nprobably need to do something like this (minimally tested).\n\n-- >8 --\nTeach \"am\" and \"rebase\" to mark the original position with ORIG_HEAD\n\n\"merge\" and \"reset\" leave the original point in history in ORIG_HEAD,\nwhich makes it easy to go back to where you were before you inflict a\nmajor damage to your history and realize that you do not like the result\nat all. These days with reflog, we technically do not need to use\nORIG_HEAD, but it is a handy way nevertheless.\n\nThis teaches \"am\" and \"rebase\" (all forms --- the vanilla one that uses\n\"am\" as its backend, \"-m\" variant that cherry-picks, and \"--interactive\")\nto do the same.\n\nSigned-off-by: Junio C Hamano \n---\n git-am.sh | 1 +\n git-rebase--interactive.sh | 1 +\n git-rebase.sh | 2 +-\n 3 files changed, 3 insertions(+), 1 deletions(-)\n\ndiff --git a/git-am.sh b/git-am.sh\nindex 2c517ed..fe53608 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -241,6 +241,7 @@ else\n \t\t: >\"$dotest/rebasing\"\n \telse\n \t\t: >\"$dotest/applying\"\n+\t\tgit update-ref ORIG_HEAD HEAD\n \tfi\n fi\n \ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex a64d9d5..02d7e3c 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -549,6 +549,7 @@ EOF\n \t\thas_action \"$TODO\" ||\n \t\t\tdie_abort \"Nothing to do\"\n \n+\t\tgit update-ref ORIG_HEAD $HEAD\n \t\toutput git checkout $ONTO && do_rest\n \t\t;;\n \tesac\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex e2d85ee..2597d77 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -378,7 +378,7 @@ fi\n echo \"First, rewinding head to replay your work on top of it...\"\n git checkout \"$onto^0\" >/dev/null 2>&1 ||\n \tdie \"could not detach HEAD\"\n-# git reset --hard \"$onto^0\"\n+git update-ref ORIG_HEAD $branch\n \n # If the $onto is a proper descendant of the tip of the branch, then\n # we just fast forwarded.\n"},{"id":"82435","messageId":"20080707111803.GF31490@mit.edu","threadId":"14316","inReplyTo":"7vbq1a8ay3.fsf@gitster.siamese.dyndns.org","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2008-07-07T11:18:03Z","receivedAt":"2008-07-07T11:18:03Z","isPatch":true,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Sun, Jul 06, 2008 at 11:28:36PM -0700, Junio C Hamano wrote:\n> The idea behind ORIG_HEAD is to have an anchoring point before an\n> operation that moves your HEAD in a drastic way. Think if it as a\n> poor-man's reflog -- in fact it predates reflog.\n> \n> That is why reset saves away the HEAD before it does its thing, so that\n> you can easily say \"Oops, I did not mean it -- reset ORIG_HEAD\" to flip\n> back to the previous state. Both a fast-forward merge and a real merge\n> can be undone by resetting back to ORIG_HEAD.\n> \n> So in that sense:\n> \n> (1) ORIG_HEAD is not strictly necessary these days, because we have\n> reflogs;\n\nTrue, but (and please correct me if I'm wrong) ORIG_HEAD will always\nbe pointing out HEAD before the user typed pretty much any git\nporcelein command (which saves HEAD into ORIG_HEAD), but with reflogs,\nit you have to paw through multiple HEAD@{n} to find the 'n' which\ncorresponds to state before executing the git plumbing command, since\nmultiple git plumbing commands could have updated the HEAD's reflog,\nright?\n\nOne of the things that's been on my 'twoud be nice list is having an\noption to \"git reflog show\" which prints the timestamp associated with\neach reflog entry, since tools like guilt tend to create quite a few\nreflog entries, and looking at the time stamps is one of the easier\nways to disentangle it. For now what I tend to do is expand my\nterminal window so it's super wide, and then look at the raw\n.git/logs/HEAD file directly.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"82436","messageId":"m34p71gbuk.fsf@localhost.localdomain","threadId":"14316","inReplyTo":"20080707111803.GF31490@mit.edu","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-07-07T11:42:02Z","receivedAt":"2008-07-07T11:42:02Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Theodore Tso writes:\n\n> On Sun, Jul 06, 2008 at 11:28:36PM -0700, Junio C Hamano wrote:\n> > The idea behind ORIG_HEAD is to have an anchoring point before an\n> > operation that moves your HEAD in a drastic way. Think if it as a\n> > poor-man's reflog -- in fact it predates reflog.\n> > \n> > That is why reset saves away the HEAD before it does its thing, so that\n> > you can easily say \"Oops, I did not mean it -- reset ORIG_HEAD\" to flip\n> > back to the previous state. Both a fast-forward merge and a real merge\n> > can be undone by resetting back to ORIG_HEAD.\n> > \n> > So in that sense:\n> > \n> > (1) ORIG_HEAD is not strictly necessary these days, because we have\n> > reflogs;\n> \n> True, but (and please correct me if I'm wrong) ORIG_HEAD will always\n> be pointing out HEAD before the user typed pretty much any git\n> porcelein command (which saves HEAD into ORIG_HEAD), but with reflogs,\n> it you have to paw through multiple HEAD@{n} to find the 'n' which\n> corresponds to state before executing the git plumbing command, since\n> multiple git plumbing commands could have updated the HEAD's reflog,\n> right?\n\nYou can always use _branch_ reflog, either in the @{1} form,\nor in @{1} shortcut form. @{1} should be equovalent to ORIG_HEAD\neven for rebase.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"82451","messageId":"33AA0978-99F2-4BF0-840B-BB4781A23217@silverinsanity.com","threadId":"14316","inReplyTo":"7vvdzi5fl5.fsf@gitster.siamese.dyndns.org","subject":"Re: Re* [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-07-07T14:36:14Z","receivedAt":"2008-07-07T14:36:14Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jul 7, 2008, at 3:16 AM, Junio C Hamano wrote:\n\n> Nanako Shiraishi writes:\n>\n>> Doesn't this make the behavior of the command inconsistent between\n>> \"git-rebase\" and \"git-rebase -m\"?\n>\n> Hmm, it makes \"rebase -i\" different, too. Luckily, I haven't pushed\n> anything out, so I can rewind and all I lose is just a few dozens of\n> minutes.\n\nAh, I missed the exit in the $do_merge conditional. Bah. I had \nconsidered rebase--interactive a completely different beast and didn't \nconsider it at all. We've moved a little beyond my goal of \"always \nget git-pull to set ORIG_HEAD.\" However, consistency is a higher \ngoal. :-)\n\nI originally only set ORIG_HEAD if rebase was operating on the current \nHEAD. Now we're setting it to the original state of the branch rebase \nis operating on. Thinking about it, I'm not certain this is what we \nwant. Should ORIG_HEAD refer the the previous state of HEAD, or to \nthe previous state of the current branch?\n\n> The one from Brian has another serious issue. That patch does not \n> allow\n> you to refer to ORIG_HEAD during conflict resolution, which is quite\n> different from how \"merge\" lets you use ORIG_HEAD. We need to set\n> ORIG_HEAD upfront if we want to tell user that ORIG_HEAD can be \n> reliably\n> used across workflows the same way to name where we were before.\n\nI was under the impression that this was not desired. I originally \nget ORIG_HEAD up front, and was told that it should happen much later \nin the process so that a reset during conflict resolution wouldn't \nblow it away.\n\n> When we correctly update \"rebase\" to do this, because one codepath \n> of it\n> uses \"am\" as its backend, we cannot use the patch I sent out \n> earlier. We\n> probably need to do something like this (minimally tested).\n\n\nThe patch looks correct to me, other than my question of what \nORIG_HEAD should be set to after \"git rebase upstream other_branch\".\n\n~~ Brian\n"},{"id":"82452","messageId":"B8E7062C-8CE6-492B-BDB4-91993140739B@silverinsanity.com","threadId":"14316","inReplyTo":"20080707111803.GF31490@mit.edu","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-07-07T14:36:29Z","receivedAt":"2008-07-07T14:36:29Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jul 7, 2008, at 7:18 AM, Theodore Tso wrote:\n\n> On Sun, Jul 06, 2008 at 11:28:36PM -0700, Junio C Hamano wrote:\n>> (1) ORIG_HEAD is not strictly necessary these days, because we have\n>> reflogs;\n>\n> True, but (and please correct me if I'm wrong) ORIG_HEAD will always\n> be pointing out HEAD before the user typed pretty much any git\n> porcelein command (which saves HEAD into ORIG_HEAD), but with reflogs,\n> it you have to paw through multiple HEAD@{n} to find the 'n' which\n> corresponds to state before executing the git plumbing command, since\n> multiple git plumbing commands could have updated the HEAD's reflog,\n> right?\n\nThis is _exactly_ why I wanted `pull --rebase` to set ORIG_HEAD. \nReflogs are great in their own way, but having ORIG_HEAD regularly \nbeing available for a quick way to set it back or refer to the \noriginal state is just too useful.\n\n~~ Brian\n"},{"id":"82460","messageId":"F0AD23BC-FA9A-4593-8942-228C428B661E@silverinsanity.com","threadId":"14316","inReplyTo":"m34p71gbuk.fsf@localhost.localdomain","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-07-07T15:03:46Z","receivedAt":"2008-07-07T15:03:46Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jul 7, 2008, at 7:42 AM, Jakub Narebski wrote:\n\n> Theodore Tso writes:\n>\n>> True, but (and please correct me if I'm wrong) ORIG_HEAD will always\n>> be pointing out HEAD before the user typed pretty much any git\n>> porcelein command (which saves HEAD into ORIG_HEAD), but with \n>> reflogs,\n>> it you have to paw through multiple HEAD@{n} to find the 'n' which\n>> corresponds to state before executing the git plumbing command, since\n>> multiple git plumbing commands could have updated the HEAD's reflog,\n>> right?\n>\n> You can always use _branch_ reflog, either in the @{1} form,\n> or in @{1} shortcut form. @{1} should be equovalent to ORIG_HEAD\n> even for rebase.\n\nI personally expected @{1} to be identical to HEAD@{1}. Since \nomitting a ref usually refers to HEAD, why shouldn't omitting it when \nreferring to the reflogs mean the HEAD log? The definition of @{1} is \nuseful since there's no other easy way to get \"current branch's \nreflog\", but I think it's non-obvious. (Since HEAD@{1} is something \ncompletely different, I think the only other way to refer to @{1} is $ \n(git symbolic-ref)@{1}.)\n\nAlso, your statement is only true if ORIG_HEAD was on the branch you \nare currently working. If we want ORIG_HEAD to mean \"state of HEAD \nbefore last command\", then \"git rebase upstream topic\" from master \nshould leave ORIG_HEAD pointing to master, not topic@{1}. It also is \nno longer true if you switch branches. Having ORIG_HEAD set to the \npoint before a pull is useful to compare multiple branches to both the \nold and new position of your updated branch.\n\nIf we're going to have ORIG_HEAD set by _any_ command, we should \nprobably come up with some consistent definition of it and set it \nappropriately. The first place most people encounter ORIG_HEAD is \nafter a pull, where it acts something like a reverse of FETCH_HEAD \n(old state of local vs. new state of remote). However, pull only sets \nORIG_HEAD by way of merge and reset sets ORIG_HEAD as well. So the \ncurrent definition appears to be \"the prior state of the last branch \nto be drastically changed.\" By this definition, ORIG_HEAD should be \nset by am and rebase as per Junio's patch.\n\nYou could make an argument for removing ORIG_HEAD, it's functionality \nbeing replaced by the reflogs. At this point, it's a rather \nestablished bit of git, and I think has usefulness of it's own.\n\n~~ Brian\n"},{"id":"82475","messageId":"7vlk0d4lky.fsf@gitster.siamese.dyndns.org","threadId":"14316","inReplyTo":"20080707111803.GF31490@mit.edu","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-07T18:04:45Z","receivedAt":"2008-07-07T18:04:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso writes:\n\n> True, but (and please correct me if I'm wrong) ORIG_HEAD will always\n> be pointing out HEAD before the user typed pretty much any git\n> porcelein command (which saves HEAD into ORIG_HEAD), but with reflogs,\n> it you have to paw through multiple HEAD@{n} to find the 'n' which\n> corresponds to state before executing the git plumbing command, since\n> multiple git plumbing commands could have updated the HEAD's reflog,\n> right?\n\nYou can inspect HEAD's reflog for individual steps, or the branch's reflog\nfor the aggregated moves (try rebasing a few patches on 'test' branch and\ninspect \"git log -g HEAD\" and \"git log -g test\").\n\n> One of the things that's been on my 'twoud be nice list is having an\n> option to \"git reflog show\" which prints the timestamp associated with\n> each reflog entry,\n\n\t$ git log -g HEAD@{now}\n $ git log -g test@{now}\n\nPlease don't complain that interface to specify timestamp output is dirty\nto me -- I share the same feeling, and it was not my invention. But at\nleast it works ;-)\n"},{"id":"82497","messageId":"7vod591hlp.fsf@gitster.siamese.dyndns.org","threadId":"14316","inReplyTo":"7vbq1a8ay3.fsf@gitster.siamese.dyndns.org","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-07T21:58:58Z","receivedAt":"2008-07-07T21:58:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> The idea behind ORIG_HEAD is to have an anchoring point before an\n> operation that moves your HEAD in a drastic way. Think if it as a\n> poor-man's reflog -- in fact it predates reflog.\n>\n> That is why reset saves away the HEAD before it does its thing, so that\n> you can easily say \"Oops, I did not mean it -- reset ORIG_HEAD\" to flip\n> back to the previous state. Both a fast-forward merge and a real merge\n> can be undone by resetting back to ORIG_HEAD.\n\nI've also seen people complain (quite rightfully) that these FOO_HEAD\npseudo refs are not documented in a central place.\n\nHow about doing this? It should make it clear what ORIG_HEAD is meant to\nrecord, while describing others.\n\nAnd to answer your \"git rebase --onto this from that-branch\" question, I\nthink ORIG_HEAD should record the tip of that-branch before rebase takes\nplace, not the commit you happened to be at before running it. Switching\nbranch to that-branch is not the drastic and unforseeable part. The\ndrastic and unforseeable change is rebasing and seeing that the rebased\nresult does not work with the new upstream `from`, and the user would want\nto have a way to quickly rewind the tip of the branch back to the state\nbefore the rebase. The new paragraph added by this patch should hopefully\nmake this reasoning more clear.\n\n-- >8 --\nDocumentation: update sections on naming revisions and revision ranges\n\nVarious *_HEAD pseudo refs were not documented in any central place.\nEspecially since we may be teaching rebase and am to record ORIG_HEAD,\nit would be a good time to do so.\n\nWhile at it, reword the explanation on r1..r2 notation to reduce\nconfusion.\n\nSigned-off-by: Junio C Hamano \n---\n\n Documentation/git-rev-parse.txt | 20 +++++++++++++++-----\n 1 files changed, 15 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt\nindex 378a312..7184274 100644\n--- a/Documentation/git-rev-parse.txt\n+++ b/Documentation/git-rev-parse.txt\n@@ -166,7 +166,7 @@ blobs contained in a commit.\n first match in the following rules:\n \n . if `$GIT_DIR/` exists, that is what you mean (this is usually\n- useful only for `HEAD`, `FETCH_HEAD` and `MERGE_HEAD`);\n+ useful only for `HEAD`, `FETCH_HEAD`, `ORIG_HEAD` and `MERGE_HEAD`);\n \n . otherwise, `$GIT_DIR/refs/` if exists;\n \n@@ -177,6 +177,16 @@ blobs contained in a commit.\n . otherwise, `$GIT_DIR/refs/remotes/` if exists;\n \n . otherwise, `$GIT_DIR/refs/remotes//HEAD` if exists.\n++\n+HEAD names the commit your changes in the working tree is based on.\n+FETCH_HEAD records the branch you fetched from a remote repository\n+with your last 'git-fetch' invocation.\n+ORIG_HEAD is created by commands that moves your HEAD in a drastic\n+way, to record the position of the HEAD before their operation, so that\n+you can change the tip of the branch back to the state before you ran\n+them easily.\n+MERGE_HEAD records the commit(s) you are merging into your branch\n+when you run 'git-merge'.\n \n * A ref followed by the suffix '@' with a date specification\n enclosed in a brace\n@@ -289,10 +299,10 @@ notation is used. E.g. \"`{caret}r1 r2`\" means commits reachable\n from `r2` but exclude the ones reachable from `r1`.\n \n This set operation appears so often that there is a shorthand\n-for it. \"`r1..r2`\" is equivalent to \"`{caret}r1 r2`\". It is\n-the difference of two sets (subtract the set of commits\n-reachable from `r1` from the set of commits reachable from\n-`r2`).\n+for it. When you have two commits `r1` and `r2` (named according\n+to the syntax explained in SPECIFYING REVISIONS above), you can ask\n+for commits that are reachable from r2 but not from r1 by\n+\"`{caret}r1 r2`\" and it can be written as \"`r1..r2`\".\n \n A similar notation \"`r1\\...r2`\" is called symmetric difference\n of `r1` and `r2` and is defined as\n"},{"id":"82499","messageId":"m3tzf1e3ze.fsf@localhost.localdomain","threadId":"14316","inReplyTo":"7vod591hlp.fsf@gitster.siamese.dyndns.org","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-07-07T22:14:49Z","receivedAt":"2008-07-07T22:14:49Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano writes:\n\n> -- >8 --\n> Documentation: update sections on naming revisions and revision ranges\n[...]\n> While at it, reword the explanation on r1..r2 notation to reduce\n> confusion.\n\n\n> diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt\n> index 378a312..7184274 100644\n> --- a/Documentation/git-rev-parse.txt\n> +++ b/Documentation/git-rev-parse.txt\n\n> @@ -289,10 +299,10 @@ notation is used. E.g. \"`{caret}r1 r2`\" means commits reachable\n> from `r2` but exclude the ones reachable from `r1`.\n> \n> This set operation appears so often that there is a shorthand\n> -for it. \"`r1..r2`\" is equivalent to \"`{caret}r1 r2`\". It is\n> -the difference of two sets (subtract the set of commits\n> -reachable from `r1` from the set of commits reachable from\n> -`r2`).\n> +for it. When you have two commits `r1` and `r2` (named according\n> +to the syntax explained in SPECIFYING REVISIONS above), you can ask\n> +for commits that are reachable from r2 but not from r1 by\n> +\"`{caret}r1 r2`\" and it can be written as \"`r1..r2`\".\n\nI'm not sure if the last part is improvement, and it wouldn't be better\nto say rather than r1..r2 / ^r1 r2 are \"commits that are reachable from\nr2, excluding those commits which are reachable from r1\" (which translates\ninto set difference / subtracting set of commits.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"82500","messageId":"7vk5fx1g0a.fsf@gitster.siamese.dyndns.org","threadId":"14316","inReplyTo":"m3tzf1e3ze.fsf@localhost.localdomain","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-07T22:33:25Z","receivedAt":"2008-07-07T22:33:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n>> @@ -289,10 +299,10 @@ notation is used. E.g. \"`{caret}r1 r2`\" means commits reachable\n>> from `r2` but exclude the ones reachable from `r1`.\n>> \n>> This set operation appears so often that there is a shorthand\n>> -for it. \"`r1..r2`\" is equivalent to \"`{caret}r1 r2`\". It is\n>> -the difference of two sets (subtract the set of commits\n>> -reachable from `r1` from the set of commits reachable from\n>> -`r2`).\n>> +for it. When you have two commits `r1` and `r2` (named according\n>> +to the syntax explained in SPECIFYING REVISIONS above), you can ask\n>> +for commits that are reachable from r2 but not from r1 by\n>> +\"`{caret}r1 r2`\" and it can be written as \"`r1..r2`\".\n>\n> I'm not sure if the last part is improvement, and it wouldn't be better\n> to say rather than r1..r2 / ^r1 r2 are \"commits that are reachable from\n> r2, excluding those commits which are reachable from r1\" (which translates\n> into set difference / subtracting set of commits.\n\nI tried to make it easier to understand by people without having to know\nwhat a set difference is, and that was the reason I did not use \"subtract\"\nnor \"difference\", as I saw somebody was quoting the above part in #git was\nwondering what it was talking about.\n"},{"id":"82503","messageId":"200807080058.56346.jnareb@gmail.com","threadId":"14316","inReplyTo":"7vk5fx1g0a.fsf@gitster.siamese.dyndns.org","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-07-07T22:58:54Z","receivedAt":"2008-07-07T22:58:54Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski writes:\n> \n>>> @@ -289,10 +299,10 @@ notation is used. E.g. \"`{caret}r1 r2`\" means commits reachable\n>>> from `r2` but exclude the ones reachable from `r1`.\n>>> \n>>> This set operation appears so often that there is a shorthand\n>>> -for it. \"`r1..r2`\" is equivalent to \"`{caret}r1 r2`\". It is\n>>> -the difference of two sets (subtract the set of commits\n>>> -reachable from `r1` from the set of commits reachable from\n>>> -`r2`).\n>>> +for it. When you have two commits `r1` and `r2` (named according\n>>> +to the syntax explained in SPECIFYING REVISIONS above), you can ask\n>>> +for commits that are reachable from r2 but not from r1 by\n>>> +\"`{caret}r1 r2`\" and it can be written as \"`r1..r2`\".\n>>\n>> I'm not sure if the last part is improvement, and it wouldn't be better\n>> to say rather than r1..r2 / ^r1 r2 are \"commits that are reachable from\n>> r2, excluding those commits which are reachable from r1\" (which translates\n>> into set difference / subtracting set of commits.\n> \n> I tried to make it easier to understand by people without having to know\n> what a set difference is, and that was the reason I did not use \"subtract\"\n> nor \"difference\", as I saw somebody was quoting the above part in #git was\n> wondering what it was talking about.\n\nI understand, and the replacement you proposed is better, as it does\nnot require understanding of [mathematical] set operations. I just\nthink that \"commits that are reachable from r2, excluding those commits\nwhich are reachable from r1\" could be better than \"commits that are\nreachable from r2 but not from r1\".\n\n-- \nJakub Narebski\nPoland\n"},{"id":"82531","messageId":"35BBB0D4-B3E1-4097-AF11-E0F6223125EA@silverinsanity.com","threadId":"14316","inReplyTo":"7vod591hlp.fsf@gitster.siamese.dyndns.org","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-07-08T03:24:23Z","receivedAt":"2008-07-08T03:24:23Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jul 7, 2008, at 5:58 PM, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n>\n> And to answer your \"git rebase --onto this from that-branch\" \n> question, I\n> think ORIG_HEAD should record the tip of that-branch before rebase \n> takes\n> place, not the commit you happened to be at before running it. \n> Switching\n> branch to that-branch is not the drastic and unforseeable part. The\n> drastic and unforseeable change is rebasing and seeing that the \n> rebased\n> result does not work with the new upstream `from`, and the user \n> would want\n> to have a way to quickly rewind the tip of the branch back to the \n> state\n> before the rebase. The new paragraph added by this patch should \n> hopefully\n> make this reasoning more clear.\n\nI just wanted to make sure there was a clear reasoning and to see if \nsomeone could word it clearly, as I was getting a little cross-eyed.\n\n> -- >8 --\n> Documentation: update sections on naming revisions and revision ranges\n>\n> Various *_HEAD pseudo refs were not documented in any central place.\n> Especially since we may be teaching rebase and am to record ORIG_HEAD,\n> it would be a good time to do so.\n\nMy only objection is to the \"may\". ;-)\n\nAlso, perhaps we should either list the commands that set ORIG_HEAD, \nor add a note to that effect in their manpages. I'll see what wording \nI can come up with, unless you (or someone else) gets to it first of \ncourse.\n\n> While at it, reword the explanation on r1..r2 notation to reduce\n> confusion.\n\nLooks good.\n\n~~ Brian\n"},{"id":"82533","messageId":"76718490807072028o7e0661a8r6d118cc91dc5e625@mail.gmail.com","threadId":"14316","inReplyTo":"7vod591hlp.fsf@gitster.siamese.dyndns.org","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2008-07-08T03:28:15Z","receivedAt":"2008-07-08T03:28:15Z","isPatch":true,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Mon, Jul 7, 2008 at 5:58 PM, Junio C Hamano wrote:\n> +HEAD names the commit your changes in the working tree is based on.\n\nHow about:\n\n\"HEAD names the commit your working tree is based on. This is the tip\nof the checked out branch, unless HEAD is detached. (HEAD is said to\nbe detached if a commit is checked out which is not the tip of any\nbranch.)\"\n\n> +FETCH_HEAD records the branch you fetched from a remote repository\n> +with your last 'git-fetch' invocation.\n\nconsistency w/above: s/records/names/\n\n> +ORIG_HEAD is created by commands that moves your HEAD in a drastic\n> +way, to record the position of the HEAD before their operation, so that\n> +you can change the tip of the branch back to the state before you ran\n> +them easily.\n\ns/moves/move/; s/can change/can easily change/; s/them easily./them./;\n\nBut maybe this reads better:\n\nORIG_HEAD is created by commands that move HEAD in a drastic way to\nrecord the position of HEAD before their operation, so that the branch\ncan easily be reset back to its prior state.\n\n> +MERGE_HEAD records the commit(s) you are merging into your branch\n> +when you run 'git-merge'.\n\nSo it's the \"\" arg or args mentioned in the git-merge man page?\n\nj.\n"},{"id":"82540","messageId":"1215490342-46590-1-git-send-email-benji@silverinsanity.com","threadId":"14316","inReplyTo":"35BBB0D4-B3E1-4097-AF11-E0F6223125EA@silverinsanity.com","subject":"[PATCH] Documentation: mention ORIG_HEAD in am, merge, and rebase","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-07-08T04:12:22Z","receivedAt":"2008-07-08T04:12:22Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"Merge has always set ORIG_HEAD but never mentioned it, while we\nrecently added it to am and rebase. These facts should be reflected\nin the documentation.\n\ngit-reset also sets ORIG_HEAD, but that fact is already mentioned in\nthe very first example so no changes were needed there.\n\nSigned-off-by: Brian Gernhardt \n---\n Documentation/git-am.txt | 6 ++++++\n Documentation/git-merge.txt | 4 +++-\n Documentation/git-rebase.txt | 3 ++-\n 3 files changed, 11 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-am.txt b/Documentation/git-am.txt\nindex 3863eeb..88ca5f1 100644\n--- a/Documentation/git-am.txt\n+++ b/Documentation/git-am.txt\n@@ -145,6 +145,12 @@ directory exists, so if you decide to start over from scratch,\n run `rm -f -r .dotest` before running the command with mailbox\n names.\n \n+Before any patches are applied, ORIG_HEAD is set to the tip of the\n+current branch. This is useful if you have problems with multiple\n+commits, like running 'git am' on the wrong branch or an error in the\n+commits that is more easily fixed by changing the mailbox (e.g.\n+errors in the \"From:\" lines).\n+\n \n SEE ALSO\n --------\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex 62f99b5..019e4ca 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -81,7 +81,9 @@ Otherwise, merge will refuse to do any harm to your repository\n (that is, it may fetch the objects from remote, and it may even\n update the local branch used to keep track of the remote branch\n with `git pull remote rbranch:lbranch`, but your working tree,\n-`.git/HEAD` pointer and index file are left intact).\n+`.git/HEAD` pointer and index file are left intact). In addition,\n+merge always sets `.git/ORIG_HEAD` to the original state of HEAD so\n+a problematic merge can be removed by using `git reset ORIG_HEAD`.\n \n You may have local modifications in the working tree files. In\n other words, 'git-diff' is allowed to report changes.\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex f3459c7..37382c4 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -26,7 +26,8 @@ of commits that would be shown by `git log ..HEAD`.\n \n The current branch is reset to , or if the\n --onto option was supplied. This has the exact same effect as\n-`git reset --hard ` (or ).\n+`git reset --hard ` (or ). This includes setting\n+ORIG_HEAD to the pre-rebase tip of the branch.\n \n The commits that were previously saved into the temporary area are\n then reapplied to the current branch, one by one, in order. Note that\n-- \n1.5.6.2.393.g45096\n"},{"id":"82544","messageId":"20080708042607.GC7186@sigill.intra.peff.net","threadId":"14316","inReplyTo":"F0AD23BC-FA9A-4593-8942-228C428B661E@silverinsanity.com","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-07-08T04:26:07Z","receivedAt":"2008-07-08T04:26:07Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 07, 2008 at 11:03:46AM -0400, Brian Gernhardt wrote:\n\n> I personally expected @{1} to be identical to HEAD@{1}. Since omitting a \n> ref usually refers to HEAD, why shouldn't omitting it when referring to \n> the reflogs mean the HEAD log? The definition of @{1} is useful since \n> there's no other easy way to get \"current branch's reflog\", but I think \n> it's non-obvious. (Since HEAD@{1} is something completely different, I \n> think the only other way to refer to @{1} is $(git symbolic-ref)@{1}.)\n\nFYI, there was much discussion about this exact point:\n\n http://thread.gmane.org/gmane.comp.version-control.git/38379\n\n(I don't know that it has that much bearing on the current discussion,\nbut since I went to the trouble of digging it up, I thought you might\nfind it useful).\n\n-Peff\n"},{"id":"82604","messageId":"D66F511D-CDBE-4261-AA28-07ED73F6C593@silverinsanity.com","threadId":"14316","inReplyTo":"20080708042607.GC7186@sigill.intra.peff.net","subject":"Re: [FIXED PATCH] Make rebase save ORIG_HEAD if changing current branch","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-07-08T14:32:28Z","receivedAt":"2008-07-08T14:32:28Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jul 8, 2008, at 12:26 AM, Jeff King wrote:\n\n> On Mon, Jul 07, 2008 at 11:03:46AM -0400, Brian Gernhardt wrote:\n>\n>> I personally expected @{1} to be identical to HEAD@{1}. Since \n>> omitting a\n>> ref usually refers to HEAD, why shouldn't omitting it when \n>> referring to\n>> the reflogs mean the HEAD log? The definition of @{1} is useful \n>> since\n>> there's no other easy way to get \"current branch's reflog\", but I \n>> think\n>> it's non-obvious. (Since HEAD@{1} is something completely \n>> different, I\n>> think the only other way to refer to @{1} is $(git symbolic- \n>> ref)@{1}.)\n>\n> FYI, there was much discussion about this exact point:\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/38379\n>\n> (I don't know that it has that much bearing on the current discussion,\n> but since I went to the trouble of digging it up, I thought you might\n> find it useful).\n\nOh, it is useful. And, thinking about it, I agree completely. The \nsyntax isn't immediately obvious, but clear and useful. The need to \ndistinguish between HEAD@{} and $branch@{} is apparent after a \nmoment's reflection, and the chosen solution is fairly obvious at that \npoint. I just never took that moment in my day-to-day working with git.\n\nThere's even documentation for it that is clear and understandable. \nIf I was a new user to git, I would have read the documentation and \nfound it. Having used git for a while, I don't bother to look things \nup and instead try to alter git to match my three years of \nexperience. ;-)\n\nThat said, I still want clear and consistent semantics for ORIG_HEAD. \nAnd since that now (IMNSHO) exists in next, I'm happy.\n\n~~ Brian\n"},{"id":"82627","messageId":"7vmykstc1h.fsf@gitster.siamese.dyndns.org","threadId":"14316","inReplyTo":"1215490342-46590-1-git-send-email-benji@silverinsanity.com","subject":"Re: [PATCH] Documentation: mention ORIG_HEAD in am, merge, and rebase","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-07-08T19:23:54Z","receivedAt":"2008-07-08T19:23:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brian Gernhardt writes:\n\n> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n> index f3459c7..37382c4 100644\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -26,7 +26,8 @@ of commits that would be shown by `git log ..HEAD`.\n> \n> The current branch is reset to , or if the\n> --onto option was supplied. This has the exact same effect as\n> -`git reset --hard ` (or ).\n> +`git reset --hard ` (or ). This includes setting\n> +ORIG_HEAD to the pre-rebase tip of the branch.\n> \n> The commits that were previously saved into the temporary area are\n> then reapplied to the current branch, one by one, in order. Note that\n\nI found the above \"This includes\" part very hard to understand --- it took\nme three re-reads to connect \"This\" and \"the exact same effect\". Is it\njust me?\n\nI wonder if this is easier to understand:\n\n The current branch is reset to , or if the\n --onto option was supplied. This has the exact same effect as\n `git reset --hard ` (or ). ORIG_HEAD is set\n to point at the tip of the branch before this resetting happens.\n"},{"id":"82628","messageId":"4104DCD7-23D2-436E-8599-B2EB95EBD926@silverinsanity.com","threadId":"14316","inReplyTo":"7vmykstc1h.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Documentation: mention ORIG_HEAD in am, merge, and rebase","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-07-08T19:28:22Z","receivedAt":"2008-07-08T19:28:22Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Jul 8, 2008, at 3:23 PM, Junio C Hamano wrote:\n\n> Brian Gernhardt writes:\n>\n>> diff --git a/Documentation/git-rebase.txt b/Documentation/git- \n>> rebase.txt\n>> index f3459c7..37382c4 100644\n>> --- a/Documentation/git-rebase.txt\n>> +++ b/Documentation/git-rebase.txt\n>> @@ -26,7 +26,8 @@ of commits that would be shown by `git log \n>> ..HEAD`.\n>>\n>> The current branch is reset to , or if the\n>> --onto option was supplied. This has the exact same effect as\n>> -`git reset --hard ` (or ).\n>> +`git reset --hard ` (or ). This includes setting\n>> +ORIG_HEAD to the pre-rebase tip of the branch.\n>>\n>> The commits that were previously saved into the temporary area are\n>> then reapplied to the current branch, one by one, in order. Note that\n>\n> I found the above \"This includes\" part very hard to understand --- \n> it took\n> me three re-reads to connect \"This\" and \"the exact same effect\". Is \n> it\n> just me?\n\nI thought it perfectly easy to understand. ;-) But of course, I \nwrote it. I also wrote it immediately after reading the git-reset \nmanual, which is why I phrased it that way. On a fresh read, it's \nless obvious.\n\n> I wonder if this is easier to understand:\n>\n> The current branch is reset to , or if the\n> --onto option was supplied. This has the exact same effect as\n> `git reset --hard ` (or ). ORIG_HEAD is set\n> to point at the tip of the branch before this resetting \n> happens.\n\nI might say \"before the reset\" instead of \"before this resetting \nhappens\", as I find the latter slightly awkward. But that's a minor nit\n\n~~ Brian\n"}]}