Kevin Bracey <ke...@bracey.fi> writes: > On 10/09/2013 20:19, Junio C Hamano wrote: >> I am grumpy X-<. >> >> It appears that we introduced a large breakage during 1.8.4 cycle to >> the revision traversal machinery and made pathspec-limited "git log" >> pretty much useless. >> >> This command >> >> $ git log v1.8.3.1..v1.8.4 -- git-cvsserver.perl >> >> reports that a merge 766f0f8ef7 (which did not touch the specified >> path at all) touches it. >> >> Bisecting points at d0af663e (revision.c: Make --full-history >> consider more merges, 2013-05-16). >> > That merge appearing *with* --full-history would seem like correct > behaviour to me. Or at least it's what I intended.
Oh, of course. "--full-history" is about showing any pointless change, "the mainline was a lot more up-to-date and there were changes relative to a fork based on an older baseline", so your updated "log" should show that in the mainline git-cvsserver.perl has been more fresh when that merge happened. But it shouldn't appear if the user does not ask for "--full-history". > However, your particular example occurs *without*--full-history, which > suggests a problem. Yes. > I note that "gitk v1.8.3^0..v1.8.4" and "git log --parents > v1.8.3..v1.8.4" show that merge in Git 1.8.3, but not in Git 1.8.4. So > we're going partially forwards, at least. With the testcases demonstrating the cases your series fixed that all look sensible, I think it is not really an option for us to revert them; you do not have to defend it with "we are going partially forwards" ;-). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
