{"thread":{"id":"53720","subject":"Annoyance wrt ref@{1} and reflog expiry","startedAt":"2020-06-19T18:03:59Z","lastAt":"2020-06-19T21:49:55Z","messageCount":6,"participants":["Junio C Hamano","Sergey Organov","Mike Hommey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"400203","messageId":"xmqqzh8zgcfp.fsf@gitster.c.googlers.com","threadId":"53720","inReplyTo":null,"subject":"Annoyance wrt ref@{1} and reflog expiry","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-19T18:03:54Z","receivedAt":"2020-06-19T18:03:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I have been disturbed by this for a long time, but not strongly\nenough to do anything to it.\n\nThis sequence works\n\n    $ git checkout -b newbranch\n    $ git commit --allow-empty -m one\n    $ git show -s newbranch@{1}\n\nand shows the state that was immediately after the newbranch was\ncreated.\n\nBut then if you do\n\n    $ git reflog expire --expire=now refs/heads/newbranch\n    $ git commit --allow=empty -m two\n    $ git show -s newbranch@{1}\n\nyou'd be scolded with\n\n    fatal: log for 'newbranch' only has 1 entries\n\nWhile it is true that it has only 1 entry, we have enough\ninformation in that single entry that records the transition between\nthe state in which the tip of the branch was pointing at commit\n'one' to the new commit 'two' built on it, so we should be able to\nanswer \"what object newbranch was pointing at?\".  But we refuse to\ndo so.  \n\nAnd it is unintuitive.  It is understandable to the users that all\nthe ref history before \"reflog expire\" is lost---it was what the end\nuser asked Git to do.  But after creating one commit on the state\n(or do anything else that moves the ref) and finding it regrettable,\n\"git reset --hard @{1}\" should be a viable way to recover from the\nmistake made _after_ the reflog entries were expired.\n\nOpinions?\n\n"},{"id":"400204","messageId":"87o8pe3ou6.fsf@osv.gnss.ru","threadId":"53720","inReplyTo":"xmqqzh8zgcfp.fsf@gitster.c.googlers.com","subject":"Re: Annoyance wrt ref@{1} and reflog expiry","fromName":"Sergey Organov","fromEmail":"sorganov@gmail.com","sentAt":"2020-06-19T18:14:25Z","receivedAt":"2020-06-19T18:14:33Z","isPatch":false,"sender":{"key":"sorganov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8501568?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> I have been disturbed by this for a long time, but not strongly\n> enough to do anything to it.\n>\n> This sequence works\n>\n>     $ git checkout -b newbranch\n>     $ git commit --allow-empty -m one\n>     $ git show -s newbranch@{1}\n>\n> and shows the state that was immediately after the newbranch was\n> created.\n>\n> But then if you do\n>\n>     $ git reflog expire --expire=now refs/heads/newbranch\n>     $ git commit --allow=empty -m two\n>     $ git show -s newbranch@{1}\n>\n> you'd be scolded with\n>\n>     fatal: log for 'newbranch' only has 1 entries\n>\n> While it is true that it has only 1 entry, we have enough\n> information in that single entry that records the transition between\n> the state in which the tip of the branch was pointing at commit\n> 'one' to the new commit 'two' built on it, so we should be able to\n> answer \"what object newbranch was pointing at?\".  But we refuse to\n> do so.  \n>\n> And it is unintuitive.  It is understandable to the users that all\n> the ref history before \"reflog expire\" is lost---it was what the end\n> user asked Git to do.  But after creating one commit on the state\n> (or do anything else that moves the ref) and finding it regrettable,\n> \"git reset --hard @{1}\" should be a viable way to recover from the\n> mistake made _after_ the reflog entries were expired.\n>\n> Opinions?\n\nMakes sense. The first solution that comes to mind is immediately record\ncurrent state after \"reflog expire\", so that there will be 2 entries for\nthe case in question.\n\n-- Sergey\n"},{"id":"400220","messageId":"xmqqwo42g5ld.fsf@gitster.c.googlers.com","threadId":"53720","inReplyTo":"87o8pe3ou6.fsf@osv.gnss.ru","subject":"Re: Annoyance wrt ref@{1} and reflog expiry","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-19T20:31:42Z","receivedAt":"2020-06-19T20:31:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergey Organov <sorganov@gmail.com> writes:\n\n>> But then if you do\n>>\n>>     $ git reflog expire --expire=now refs/heads/newbranch\n>>     $ git commit --allow=empty -m two\n>>     $ git show -s newbranch@{1}\n>> ...\n>> And it is unintuitive.  It is understandable to the users that all\n>> the ref history before \"reflog expire\" is lost---it was what the end\n>> user asked Git to do.  But after creating one commit on the state\n>> (or do anything else that moves the ref) and finding it regrettable,\n>> \"git reset --hard @{1}\" should be a viable way to recover from the\n>> mistake made _after_ the reflog entries were expired.\n\nAnd the expiration does not have to be --expire=now; what happens\nmore often is when I expire entries older than (say) a week, the\nreflog for a topic branch that hasn't seen any activity may become\nempty.  Then I \"git am\" the new round on the same base, compare and\nthen update, perhaps like so:\n\n    ... git reflog expire has emptied the log for so/topic ...\n    $ git checkout so/topic\n    $ git log master.. ;# remind myself what the previous round had\n    $ git checkout master... ;# detach HEAD at the previous base\n    $ git am -s ./+so-v2-topic ;# apply\n    $ git range-diff @{-1}... ;# compare\n    $ git checkout -B so/topic\n\nNow, I'm used to see this work after the above:\n\n    $ git range-diff @{1}... ;# compare again just to be sure\n\nbut because there is only one entry in the reflog, which was created\nwhen the last \"checkout -B\" updated the so/topic branch, \"there is\nonly one entry\" error kicks in.\n\n> Makes sense. The first solution that comes to mind is immediately record\n> current state after \"reflog expire\", so that there will be 2 entries for\n> the case in question.\n\nPerhaps.  \n\nOr we could change the lookup side to use the value of the ref\nitself when asked for @{0}, and use the \"old\" side of the only entry\nwhen asked for @{1}.  That way, we do not need to play games with an\nartificial entry at all, which may be a better solution.\n\nI dunno.\n"},{"id":"400221","messageId":"xmqqsgeqg4zu.fsf@gitster.c.googlers.com","threadId":"53720","inReplyTo":"xmqqwo42g5ld.fsf@gitster.c.googlers.com","subject":"Re: Annoyance wrt ref@{1} and reflog expiry","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-19T20:44:37Z","receivedAt":"2020-06-19T20:44:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Or we could change the lookup side to use the value of the ref\n> itself when asked for @{0}, and use the \"old\" side of the only entry\n> when asked for @{1}.  That way, we do not need to play games with an\n> artificial entry at all, which may be a better solution.\n\nIn other words, looking up @{0} will be the only special case.  A\nnatural consequence of the above way to look up @{1} is to look at\nthe old side of (N-1)th entry in the reflog for @{N}.\n\nI am starting to like this idea, but I am not sure how tricky the\nactual implementation would be.\n"},{"id":"400223","messageId":"20200619203639.i5jto4i52ptsihrs@glandium.org","threadId":"53720","inReplyTo":"xmqqwo42g5ld.fsf@gitster.c.googlers.com","subject":"Re: Annoyance wrt ref@{1} and reflog expiry","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2020-06-19T20:36:39Z","receivedAt":"2020-06-19T20:58:04Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Fri, Jun 19, 2020 at 01:31:42PM -0700, Junio C Hamano wrote:\n> Sergey Organov <sorganov@gmail.com> writes:\n> \n> >> But then if you do\n> >>\n> >>     $ git reflog expire --expire=now refs/heads/newbranch\n> >>     $ git commit --allow=empty -m two\n> >>     $ git show -s newbranch@{1}\n> >> ...\n> >> And it is unintuitive.  It is understandable to the users that all\n> >> the ref history before \"reflog expire\" is lost---it was what the end\n> >> user asked Git to do.  But after creating one commit on the state\n> >> (or do anything else that moves the ref) and finding it regrettable,\n> >> \"git reset --hard @{1}\" should be a viable way to recover from the\n> >> mistake made _after_ the reflog entries were expired.\n> \n> And the expiration does not have to be --expire=now; what happens\n> more often is when I expire entries older than (say) a week, the\n> reflog for a topic branch that hasn't seen any activity may become\n> empty.  Then I \"git am\" the new round on the same base, compare and\n> then update, perhaps like so:\n> \n>     ... git reflog expire has emptied the log for so/topic ...\n>     $ git checkout so/topic\n>     $ git log master.. ;# remind myself what the previous round had\n>     $ git checkout master... ;# detach HEAD at the previous base\n>     $ git am -s ./+so-v2-topic ;# apply\n>     $ git range-diff @{-1}... ;# compare\n>     $ git checkout -B so/topic\n> \n> Now, I'm used to see this work after the above:\n> \n>     $ git range-diff @{1}... ;# compare again just to be sure\n> \n> but because there is only one entry in the reflog, which was created\n> when the last \"checkout -B\" updated the so/topic branch, \"there is\n> only one entry\" error kicks in.\n> \n> > Makes sense. The first solution that comes to mind is immediately record\n> > current state after \"reflog expire\", so that there will be 2 entries for\n> > the case in question.\n> \n> Perhaps.  \n> \n> Or we could change the lookup side to use the value of the ref\n> itself when asked for @{0}, and use the \"old\" side of the only entry\n> when asked for @{1}.  That way, we do not need to play games with an\n> artificial entry at all, which may be a better solution.\n\nOr more generally, use the old side from @{n} when asked for @{n+1} when\nthere are only n entries in the reflog.\n\nMike\n"},{"id":"400226","messageId":"xmqqblleg1z7.fsf@gitster.c.googlers.com","threadId":"53720","inReplyTo":"20200619203639.i5jto4i52ptsihrs@glandium.org","subject":"Re: Annoyance wrt ref@{1} and reflog expiry","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-06-19T21:49:48Z","receivedAt":"2020-06-19T21:49:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Mike Hommey <mh@glandium.org> writes:\n\n>> Or we could change the lookup side to use the value of the ref\n>> itself when asked for @{0}, and use the \"old\" side of the only entry\n>> when asked for @{1}.  That way, we do not need to play games with an\n>> artificial entry at all, which may be a better solution.\n>\n> Or more generally, use the old side from @{n} when asked for @{n+1} when\n> there are only n entries in the reflog.\n\nYup, I agree that it is the natural consequence.\n"}]}