Re: [PATCH 5/5] Enable ref log creation in git checkout -b.

From: Junio C Hamano <junkio@cox.net>
Date: May 24, 2006, 23:18 UTC
Message-ID: <7vy7wr3tc3.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060524035234.GA13329@spearce.org>

Shawn Pearce <spearce@spearce.org> writes:

Show 9 quoted lines

> Junio C Hamano <junkio@cox.net> wrote:
>> I've swallowed all 10 and pushed them out in "pu", but could you
>> add tests to check the Porcelainish commands you touched with
>> this series to make sure they all log correctly?
>
> Sure.  I've been putting it off as I've been busy the past few days
> and have also been thinking about trying to rebuild reflog using a
> tag/annotation branch style, which might be more generally useful
> to others.

It appears that there is more serious breakage caused by the lock_ref change. http-fetch in "next" fails to clone, because the call to lock-ref-sha1 in fetch.c::pull() forgets that the program might be creating a new ref.

Another breakage I found (not related to ref-log) is that it appears fetch.c, even in "master" branch [*1*], has current_ref variable and does things depending on it, but nobody seems to set that variable, so there are a lot of dead code that looks as if they are doing something useful, enclosed in sections like:

	if (somethingelse && current_ref) {
        	dead code
	}

I'll probably revert the ref-log series from "next" in the next round of updates, while killing the current_ref variable from "master".

[Footnotes]

*1* It actually is worse than that. Commit cd541a6 introduced this variable but nobody touches it ever in the development history of that variable. I wonder what the original author and the maintainer were smoking back then...