Re: Deleting remote branches with git-branch and reflog questions

[Nicolas Pitre <nico@cam.org>]

[ please CC me when replying, please ]

On Wed, 24 Jan 2007, Jakub Narebski wrote:

> Nicolas Pitre wrote:
> 
> > On Tue, 23 Jan 2007, Junio C Hamano wrote:
> > 
> >> Nicolas Pitre <nico@cam.org> writes:
> >> 
> >>> On Tue, 23 Jan 2007, Junio C Hamano wrote:
> >>>
> >>>> And we might want to allow reflogs on detached HEAD someday,
> >>>> although I personally think it goes against what detached HEAD
> >>>> is -- it is of a very temporary nature.
> >>>
> >>> Didn't we agree already that reflog with detached head was simply 
> >>> insane?
> >> 
> >> Perhaps, perhaps not.
> >> 
> >>      $ git checkout v2.6.14
> >>      $ git checkout v2.6.15
> >>      $ git checkout v2.6.16
> >> 
> >> Ah, which one did I check-out the last time?
> >> 
> >>      $ git describe HEAD@{1}
> > 
> > And what does HEAD@{1} means if not detached?
> > 
> > If there is a reflog for HEAD independently of what branch HEAD is 
> > attached to then it could make sense.  Meaning that if you're on branch 
> > "master" and perform a commit, then both reflogs for "master" and "HEAD" 
> > are updated at the same time.  If you then checkout branch "next" then 
> > only the "HEAD" reflog is updated since no changes to any branch did 
> > occur but just HEAD changed.
> > 
> > Then moving around and/or committing with a detached head would just 
> > update the "HEAD reflog.
> 
> I think it would be best to maintain mixed approach. When we are on some
> branch, the HEAD@{1} would mean <current branch>@{1}. When HEAD is detached
> (is not symlink or symref), HEAD@{1} means it's latest state. Detaching
> a head creates reflog, de-detaching deletes it...

Please no.  I think this is exactly the absolutely worst thing you could 
have.  Better not have any reflog for detached heads at all.

First, if you're not playing with detached heads then you don't care 
since it makes no difference.

But if you do use a detached head then having HEAD@{n} suddenly change 
from one universe to another just because you detached or attached HEAD 
from/to a branch is insane.

Consider HEAD@{1} when you just detached from a branch?  According to 
your suggestion it would point into the void.

And why wouldn't HEAD@{1} refer back to a detached state right after 
checking out a branch?  According to your suggestion the last detached 
position is now lost.  Worse, it will point to a commit which might have 
nothing to do with the previous operation I performed with my repository 
which is IMHO against the spirit of a reflog for "HEAD".


Nicolas