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

Re: [RFH] revision limiting sometimes ignored

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 6, 2008, 06:17 UTC
Message-ID
<7vd4ra4nid.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<7vhcgm4o1p.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 28 quoted lines
> Once we find the set of bottom commits in "newlist", we would
> need to prove that none of them can be reached from any of the
> negative commits still in "list".  We can do this traversal
> using two bits from flags, exactly like commit.c::merge_bases()
>
>     for each bottom commit B {
>       L = empty list
>       B.flags |= PARENT2
>       L.append(B)
>       for each negative commit C in "list from limit_list()"
>           C.flags |= PARENT1
>           L.append(C)
>       while (L) {
>           C = shift L;
>           flag = C.flags & (PARENT1|PARENT2);
>             if (flag ==  (PARENT1|PARENT2))
>               continue; /* common */
>           for each parent P of commit C:
>               pflag = P.flags & (PARENT1|PARENT2);
>               if (pflag == flag)
>                     continue;
>               P.flags |= flags;
>                 L.append(P)
>       }
>       if (B.flags & PARENT1)
>           we still need to traverse -- everybody_uninteresting()
>           in limit_list() main loop was not enough!
>     }

Actually when we do this traversal, we can mark the positive commits on "newlist" as negative when it is painted with PARENT1. I was assuming that as soon as we find that we are in problematic history with this procedure we exit the whole thing and resume to limit_list(), but we may be able to use this as the postprocessing step to clean-up the result. I just need to prove that this postprocessing step will smudge all the "falsely positive but in reality negative" ones...

Previous: Junio C HamanoNext: Junio C Hamano
Message 29 of 34 in “[BUG?] git log picks up bad commit”
  1. Tilman SauerbeckFeb 2, 2008
  2. Jeff KingFeb 3, 2008
  3. [RFH] revision limiting sometimes ignoredJeff King, Feb 3, 2008
  4. Junio C HamanoFeb 3, 2008
  5. Junio C HamanoFeb 3, 2008
  6. Jeff KingFeb 3, 2008
  7. Jeff KingFeb 3, 2008
  8. Junio C HamanoFeb 3, 2008
  9. Junio C HamanoFeb 3, 2008
  10. Junio C HamanoFeb 3, 2008
  11. Linus TorvaldsFeb 4, 2008
  12. Linus TorvaldsFeb 4, 2008
  13. Junio C HamanoFeb 4, 2008
  14. Linus TorvaldsFeb 4, 2008
  15. Linus TorvaldsFeb 4, 2008
  16. Linus TorvaldsFeb 4, 2008
  17. Junio C HamanoFeb 5, 2008
  18. Linus TorvaldsFeb 5, 2008
  19. Johannes SchindelinFeb 5, 2008
  20. Linus TorvaldsFeb 5, 2008
  21. Tilman SauerbeckFeb 6, 2008
  22. Nicolas PitreFeb 6, 2008
  23. Linus TorvaldsFeb 6, 2008
  24. Nicolas PitreFeb 6, 2008
  25. Linus TorvaldsFeb 6, 2008
  26. Nicolas PitreFeb 6, 2008
  27. Junio C HamanoFeb 6, 2008
  28. Junio C HamanoFeb 6, 2008
  29. Junio C HamanoFeb 6, 2008
  30. Junio C HamanoFeb 5, 2008
  31. Linus TorvaldsFeb 6, 2008
  32. Junio C HamanoFeb 6, 2008
  33. Karl HasselströmFeb 6, 2008
  34. Linus TorvaldsFeb 6, 2008

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.