On Wed, Mar 4, 2015 at 6:44 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Troy Moure <troy.moure@xxxxxxxxx> writes: > >> git rev-list --bisect --first-parent --parents HEAD --not HEAD~1 > > Hmm, as "rev-list --bisect" is not end-user facing command (it is > purely an implementation detail for "git bisect") and we never call > it with --first-parent, I am not sure if it is worth labelling it as > a BUG. Surely, the command can refuse to operate when it sees both > options given, but that would be a fairly low priority. Hrm, ok. I didn't realize "--bisect" is only intended to be used by git-bisect (although I suppose the fact that it treats ref/bisect/* specially should have been a hint). If uses of "--bisect" other than by git-bisect are considered unsupported, IMO it would be good to say that in the documentation - right now it looks like just another rev-list parameter. (I realize rev-list itself is "plumbing", but that's not the same as "not user facing", is it?) If you're curious, I ran into this because I am working on a script that can be run repeatedly to process commits, and uses git notes to mark commits that have been processed. Parents are always processed before their children, so if a commit has a note, it means all its ancestors also have notes. I want to quickly find the set of commits that have not yet been processed. I am thinking of finding the "boundary" commits (commits that have a note and at least one child that does not) by using a binary search to find the boundary commit on the first-parent chain, and then recursively doing the same thing starting from each non-first parent of each merge commit between the boundary commit and the starting point. Upon further thought, it's probably better to just read the whole first-parent chain and do the binary search in the script, since "git rev-list --bisect" would have generate the chain each time it's called. But I'd already run into the segfault, so I thought I'd report it. Of course, I'd appreciate any thoughts or comments on the problem I'm trying to solve as well. Thanks, Troy -- 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