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

[Jakub Narebski <jnareb@gmail.com>]

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