Annoyance wrt ref@{1} and reflog expiry

Annoyance wrt ref@{1} and reflog expiry

[Junio C Hamano]

I have been disturbed by this for a long time, but not strongly
enough to do anything to it.

This sequence works

    $ git checkout -b newbranch
    $ git commit --allow-empty -m one
    $ git show -s newbranch@{1}

and shows the state that was immediately after the newbranch was
created.

But then if you do

    $ git reflog expire --expire=now refs/heads/newbranch
    $ git commit --allow=empty -m two
    $ git show -s newbranch@{1}

you'd be scolded with

    fatal: log for 'newbranch' only has 1 entries

While it is true that it has only 1 entry, we have enough
information in that single entry that records the transition between
the state in which the tip of the branch was pointing at commit
'one' to the new commit 'two' built on it, so we should be able to
answer "what object newbranch was pointing at?".  But we refuse to
do so.  

And it is unintuitive.  It is understandable to the users that all
the ref history before "reflog expire" is lost---it was what the end
user asked Git to do.  But after creating one commit on the state
(or do anything else that moves the ref) and finding it regrettable,
"git reset --hard @{1}" should be a viable way to recover from the
mistake made _after_ the reflog entries were expired.

Opinions?

Re: Annoyance wrt ref@{1} and reflog expiry

[Sergey Organov]

Junio C Hamano <gitster@pobox.com> writes:

> I have been disturbed by this for a long time, but not strongly
> enough to do anything to it.
>
> This sequence works
>
>     $ git checkout -b newbranch
>     $ git commit --allow-empty -m one
>     $ git show -s newbranch@{1}
>
> and shows the state that was immediately after the newbranch was
> created.
>
> But then if you do
>
>     $ git reflog expire --expire=now refs/heads/newbranch
>     $ git commit --allow=empty -m two
>     $ git show -s newbranch@{1}
>
> you'd be scolded with
>
>     fatal: log for 'newbranch' only has 1 entries
>
> While it is true that it has only 1 entry, we have enough
> information in that single entry that records the transition between
> the state in which the tip of the branch was pointing at commit
> 'one' to the new commit 'two' built on it, so we should be able to
> answer "what object newbranch was pointing at?".  But we refuse to
> do so.  
>
> And it is unintuitive.  It is understandable to the users that all
> the ref history before "reflog expire" is lost---it was what the end
> user asked Git to do.  But after creating one commit on the state
> (or do anything else that moves the ref) and finding it regrettable,
> "git reset --hard @{1}" should be a viable way to recover from the
> mistake made _after_ the reflog entries were expired.
>
> Opinions?

Makes sense. The first solution that comes to mind is immediately record
current state after "reflog expire", so that there will be 2 entries for
the case in question.

-- Sergey

Re: Annoyance wrt ref@{1} and reflog expiry

[Junio C Hamano]

Sergey Organov <sorganov@gmail.com> writes:

>> But then if you do
>>
>>     $ git reflog expire --expire=now refs/heads/newbranch
>>     $ git commit --allow=empty -m two
>>     $ git show -s newbranch@{1}
>> ...
>> And it is unintuitive.  It is understandable to the users that all
>> the ref history before "reflog expire" is lost---it was what the end
>> user asked Git to do.  But after creating one commit on the state
>> (or do anything else that moves the ref) and finding it regrettable,
>> "git reset --hard @{1}" should be a viable way to recover from the
>> mistake made _after_ the reflog entries were expired.

And the expiration does not have to be --expire=now; what happens
more often is when I expire entries older than (say) a week, the
reflog for a topic branch that hasn't seen any activity may become
empty.  Then I "git am" the new round on the same base, compare and
then update, perhaps like so:

    ... git reflog expire has emptied the log for so/topic ...
    $ git checkout so/topic
    $ git log master.. ;# remind myself what the previous round had
    $ git checkout master... ;# detach HEAD at the previous base
    $ git am -s ./+so-v2-topic ;# apply
    $ git range-diff @{-1}... ;# compare
    $ git checkout -B so/topic

Now, I'm used to see this work after the above:

    $ git range-diff @{1}... ;# compare again just to be sure

but because there is only one entry in the reflog, which was created
when the last "checkout -B" updated the so/topic branch, "there is
only one entry" error kicks in.

> Makes sense. The first solution that comes to mind is immediately record
> current state after "reflog expire", so that there will be 2 entries for
> the case in question.

Perhaps.  

Or we could change the lookup side to use the value of the ref
itself when asked for @{0}, and use the "old" side of the only entry
when asked for @{1}.  That way, we do not need to play games with an
artificial entry at all, which may be a better solution.

I dunno.

Re: Annoyance wrt ref@{1} and reflog expiry

[Mike Hommey]

On Fri, Jun 19, 2020 at 01:31:42PM -0700, Junio C Hamano wrote:
> Sergey Organov <sorganov@gmail.com> writes:
> 
> >> But then if you do
> >>
> >>     $ git reflog expire --expire=now refs/heads/newbranch
> >>     $ git commit --allow=empty -m two
> >>     $ git show -s newbranch@{1}
> >> ...
> >> And it is unintuitive.  It is understandable to the users that all
> >> the ref history before "reflog expire" is lost---it was what the end
> >> user asked Git to do.  But after creating one commit on the state
> >> (or do anything else that moves the ref) and finding it regrettable,
> >> "git reset --hard @{1}" should be a viable way to recover from the
> >> mistake made _after_ the reflog entries were expired.
> 
> And the expiration does not have to be --expire=now; what happens
> more often is when I expire entries older than (say) a week, the
> reflog for a topic branch that hasn't seen any activity may become
> empty.  Then I "git am" the new round on the same base, compare and
> then update, perhaps like so:
> 
>     ... git reflog expire has emptied the log for so/topic ...
>     $ git checkout so/topic
>     $ git log master.. ;# remind myself what the previous round had
>     $ git checkout master... ;# detach HEAD at the previous base
>     $ git am -s ./+so-v2-topic ;# apply
>     $ git range-diff @{-1}... ;# compare
>     $ git checkout -B so/topic
> 
> Now, I'm used to see this work after the above:
> 
>     $ git range-diff @{1}... ;# compare again just to be sure
> 
> but because there is only one entry in the reflog, which was created
> when the last "checkout -B" updated the so/topic branch, "there is
> only one entry" error kicks in.
> 
> > Makes sense. The first solution that comes to mind is immediately record
> > current state after "reflog expire", so that there will be 2 entries for
> > the case in question.
> 
> Perhaps.  
> 
> Or we could change the lookup side to use the value of the ref
> itself when asked for @{0}, and use the "old" side of the only entry
> when asked for @{1}.  That way, we do not need to play games with an
> artificial entry at all, which may be a better solution.

Or more generally, use the old side from @{n} when asked for @{n+1} when
there are only n entries in the reflog.

Mike

Re: Annoyance wrt ref@{1} and reflog expiry

[Junio C Hamano]

Mike Hommey <mh@glandium.org> writes:

>> Or we could change the lookup side to use the value of the ref
>> itself when asked for @{0}, and use the "old" side of the only entry
>> when asked for @{1}.  That way, we do not need to play games with an
>> artificial entry at all, which may be a better solution.
>
> Or more generally, use the old side from @{n} when asked for @{n+1} when
> there are only n entries in the reflog.

Yup, I agree that it is the natural consequence.

Re: Annoyance wrt ref@{1} and reflog expiry

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Or we could change the lookup side to use the value of the ref
> itself when asked for @{0}, and use the "old" side of the only entry
> when asked for @{1}.  That way, we do not need to play games with an
> artificial entry at all, which may be a better solution.

In other words, looking up @{0} will be the only special case.  A
natural consequence of the above way to look up @{1} is to look at
the old side of (N-1)th entry in the reflog for @{N}.

I am starting to like this idea, but I am not sure how tricky the
actual implementation would be.