Re: Deleting remote branches with git-branch and reflog questions
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Jan 24, 2007, 02:22 UTC
- Message-ID
- <ep6fre$2i2$1@sea.gmane.org>
- In-Reply-To
- <Pine.LNX.4.64.0701232103290.3011@xanadu.home>
Nicolas Pitre wrote:
Show 34 quoted lines
> 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