[ 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@xxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html