Kevin Daudt <me@xxxxxxxxx> writes: > On Tue, Mar 10, 2015 at 04:12:18PM -0700, Junio C Hamano wrote: > >> What does such a command line _mean_? It tells us this: >> >> Define a set by having the "bad" ref as a positive end, and >> having all the "good" refs as negative (uninteresting) boundary. >> >> That is a way to show commits that are reachable from the bad one >> and excluding the ones that are reachable from any of the known-good >> commits. The area of the graph in the current bisection that >> contains suspect commits. >> >> Now, what does it mean to pull only the first-parent chain starting >> from the bad one in such a set in the first place? What does the >> resulting set of commits mean? > > In that case it will leave out any merged in branches. Needs a bit more thinking (hint: branches merged into *what*?). > I recalled reading something about this. Searching found me the GSoC > idea: > > When your project is strictly "new features are merged into trunk, > never the other way around", it is handy to be able to first find a > merge on the trunk that merged a topic to point fingers at when a > bug appears, instead of having to drill down to the individual > commit on the faulty side branch. > > So there is definitely a use case for --bisect --first-parent, which > would show you those commits that would be part of the bisection. 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. -- 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