On Wed, Mar 11, 2015 at 01:13:48PM -0700, Junio C Hamano wrote: > Kevin Daudt <me@xxxxxxxxx> writes: > > > On Tue, Mar 10, 2015 at 04:12:18PM -0700, Junio C Hamano wrote: > > > > Step back and think why "git bisect --first-parent" is sometimes > desired in the first place. > > It is because in the regular bisection, you will almost always end > up on a commit that is _not_ on the first-parent chain and asked to > check that commit at a random place on a side branch in the first > place. And you mark such a commit as "bad". > > The thing is, traversing from that "bad" commit that is almost > always is on a side branch, following the first-parent chain, will > not be a useful history that "leaves out any merged in branches". > > When "git bisect --first-parent" feature gets implemented, "do not > use --first-parent with --bisect" limitation has to be lifted > anyway, but until then, not allowing "--first-parent --bisect" for > "rev-list" but allowing it for "log" does not buy our users much. > The output does not give us a nice "show me which merges on the > trunk may have caused the breakage to be examined with the remainder > of this bisect session". > > So, yes, there is a use case for "log --bisect --first-parent", once > there is a working "bisect --first-parent", but not until then, the > command is not useful, I would think. Thank you for you explanation. My confusion came from incorrectly assuming refs/bisect/bad and refs/bisect/good-* were pointing to the initially specified good and bad commits, in which case the combination does make sense. I was looking in the manpages for the meaning of the bisect refs, but could only find something about refs/bisect/bad: git-bisect(1): > Eventually there will be no more revisions left to bisect, and you > will have been left with the first bad kernel revision in > "refs/bisect/bad So this ref changes to the bad commit. For refs/bisect/good-*, I could only find an example snippet: > GOOD=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*) But it's not really clear what * might be expanded to, nor what they mean. I guess this could use some clarrification in the documentation. Knowing this, I agree that the combination log --bisect --first-parent doesn't make sense either. I will send in a new patch. Kevin -- To unsubscribe from this list: 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