git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [BUG] Segfault with rev-list --bisect

From
TMTroy Moure <troy.moure@gmail.com>
Date
Mar 5, 2015, 02:15 UTC
Message-ID
<CAMo-WNaS-at4oE2xS-07O=7R4VTXLrPeDJ84c_HbikXhN-W99g@mail.gmail.com>
In-Reply-To
<xmqq61ag72gc.fsf@gitster.dls.corp.google.com>
On Wed, Mar 4, 2015 at 6:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 9 quoted lines
> Troy Moure <troy.moure@gmail.com> 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

Previous: Junio C HamanoNext: Kevin Daudt
Message 4 of 32 in “[BUG] Segfault with rev-list --bisect”
  1. Troy MoureMar 3, 2015
  2. Jeff KingMar 4, 2015
  3. Junio C HamanoMar 4, 2015
  4. Troy MoureMar 5, 2015
  5. rev-list: refuse --first-parent combined with --bisectKevin Daudt, Mar 7, 2015
  6. Kevin DaudtMar 7, 2015
  7. Junio C HamanoMar 8, 2015
  8. rev-list: refuse --first-parent combined with --bisectKevin Daudt, Mar 8, 2015
  9. rev-list: refuse --first-parent combined with --bisectKevin Daudt, Mar 8, 2015
  10. rev-list: refuse --first-parent combined with --bisectKevin Daudt, Mar 8, 2015
  11. Eric SunshineMar 8, 2015
  12. Kevin DaudtMar 9, 2015
  13. rev-list: refuse --first-parent combined with --bisectKevin Daudt, Mar 9, 2015
  14. Junio C HamanoMar 10, 2015
  15. Kevin DaudtMar 10, 2015
  16. Junio C HamanoMar 10, 2015
  17. Kevin DaudtMar 11, 2015
  18. Junio C HamanoMar 11, 2015
  19. Kevin DaudtMar 16, 2015
  20. Junio C HamanoMar 16, 2015
  21. Philip OakleyMar 16, 2015
  22. Junio C HamanoMar 16, 2015
  23. Christian CouderMar 17, 2015
  24. Junio C HamanoMar 17, 2015
  25. Christian CouderMar 17, 2015
  26. Junio C HamanoMar 17, 2015
  27. Christian CouderMar 18, 2015
  28. Philip OakleyMar 19, 2015
  29. Scott SchmitMar 20, 2015
  30. rev-list: refuse --first-parent combined with --bisectKevin Daudt, Mar 19, 2015
  31. Junio C HamanoMar 19, 2015
  32. Kevin DaudtMar 21, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.