Shawn Pearce <spearce@spearce.org> writes: > 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... - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Thu May 25 09:18:55 2006
This archive was generated by hypermail 2.1.8 : 2006-05-25 09:19:15 EST