Re: [PATCH] Detached HEAD (experimental)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Nicolas Pitre wrote:
> On Tue, 9 Jan 2007, Shawn O. Pearce wrote:
> 
>> Jakub Narebski <jnareb@xxxxxxxxx> wrote:
>>> Shawn O. Pearce wrote:
>>> 
>>>> In my mind that is a small price to pay for making sure the
>>>> commit currently in a detached HEAD doesn't get orphaned off
>>>> into never-never land.
>>> 
>>> By the way, would detached HEAD be reflogged, and if it would
>>> (and certainly it would be nice to have, because protection or
>>> not sh*t happens) how it would be implemented?
>> 
>> Ohhhhh.  It should reflog if .git/logs/HEAD exists, so long as
>> changes to HEAD are done via update-ref and not just by echo (as
>> one of Junio's versions of the feature had done).
>> 
>> Unfortunately .git/logs/HEAD wouldn't be created by default as its
>> not under refs/heads or refs/remotes.  Though it could be made to be
>> on by default, in which case it would only log changes while HEAD
>> is detached.  If HEAD is attached to a branch then .git/logs/HEAD
>> wouldn't be appended to (or even created), while the branch's own
>> log is still appended to.
> 
> Is this worth the trouble and complexity?  After all detached heads
> are not meant to be used for serious development.

I think reflogging detached HEAD is easier than adding safety checks
either on commit (no commits on top of detached HEAD), or on checkouts
and stuff (try not to loose unless forced chain of commits built on top
of detached HEAD).
-- 
Jakub Narebski
Poland
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]