Shawn Pearce <spearce@xxxxxxxxxxx> writes:
> Junio C Hamano <junkio@xxxxxxx> 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...
-
: 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