Re: What's cooking in git.git (topics)

From: Nicolas Pitre <nico@cam.org>
Date: Jan 27, 2007, 19:23 UTC
Message-ID: <Pine.LNX.4.64.0701271415280.3021@xanadu.home>
In-Reply-To: <7vps90lvoh.fsf@assigned-by-dhcp.cox.net>

On Sat, 27 Jan 2007, Junio C Hamano wrote:

Show 17 quoted lines

> * np/dreflog (Fri Jan 26 17:26:11 2007 -0500) 8 commits
>  - add reflog when moving HEAD to a new branch
>  - create_symref(): do not assume pathname from git_path() persists
>    long enough
>  - add logref support to git-symbolic-ref
>  - move create_symref() past log_ref_write()
>  - add reflog entries for HEAD when detached
>  - enable separate reflog for HEAD
>  - lock_ref_sha1_basic(): remember the original name of a ref when
>    resolving it
>  - make reflog filename independent from struct ref_lock
> 
> Perhaps 1.5.0 material, but I do not think anybody in the
> current code pays attention to reflog for HEAD ("HEAD@{....}"
> syntax and log or show-branch with -g option would look at the
> underlying ref and prune and friends do not protect its
> entries), so merge it post 1.5.0 after these issues are fixed.

I might be partial of course, but I think it is preferable to merge it before 1.5.0 since this causes a behavior change. Currently HEAD@{n} inherits the reflog of the branch HEAD is currently on. With this patch serie HEAD@{n} is the true reflog for HEAD regardless of where it is now and where it has been independently of the current branch. Of course I consider the later behavior to be more sensible and it might be a good idea to give it to 1.5.0 users at the same time as the detached head support rather than creating a behavior change later on when reflogs are more popular.

I'll look at prune and friend for teaching them about the new reflog entries.

Nicolas