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...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
-
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