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

Re: [PATCH 3/3] Make clear_commit_marks() clean harder

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Jul 3, 2006, 21:12 UTC
Message-ID
<Pine.LNX.4.63.0607032309190.29667@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To
<7vzmfqqxlh.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 3 Jul 2006, Junio C Hamano wrote:
Show 19 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> > Don't care if objects have been parsed or not and don't stop when we
> >> > reach a commit that is already clean -- its parents could be dirty.
> >> 
> >> There is something quite wrong with this patch.
> >
> > I always had the feeling that it was wrong to traverse not-yet-parsed 
> > parents: How could a revision walk possibly come to a certain commit 
> > without at least one continuous history of now-parsed objects?
> >
> > Also, AFAIK the revision walk sets flags for each commit it touched, and 
> > we should not try to be smart-asses about the flags, but just unset these 
> > flags.
> 
> The main points were made by Linus already.
> 
> Traversing is not needed -- not clearing not-yet-parsed is
> obviously wrong.

Traversing is actually wrong. Clearing the marks does not mean to clear them on commits we did not even mark!

But clearing on commits we _have_ -- but not parsed -- is important, obviously.

Show 8 quoted lines
> > BTW some very quick tests showed that the clear_commit_marks() thing that 
> > I sent to the list was much faster than traversing all objects (which was 
> > in my original version).
> 
> I have a crude workaround pushed out last night but will be
> replacing it with something less drastic.  I think the final
> version should be what you had, perhaps minus not looking at the
> parsed flag for unmarking purposes.

Isn't the right way to go about it to just clear the marks if we have a commit that has at least one of the marks set, but traverse further only if _in addition to having at least one mark set_ the commit has been parsed already?

That would not be a crude workaround.

BTW what cases could have a commit, being seen by the revision walk, not have the SEEN mark set?

Ciao, Dscho

Previous: Junio C HamanoNext: Linus Torvalds
Message 36 of 49 in “A note on merging conflicts..”
  1. Linus TorvaldsJul 1, 2006
  2. Junio C HamanoJul 1, 2006
  3. Linus TorvaldsJul 1, 2006
  4. Linus TorvaldsJul 1, 2006
  5. Rene ScharfeJul 1, 2006
  6. Johannes SchindelinJul 1, 2006
  7. Linus TorvaldsJul 1, 2006
  8. Rene ScharfeJul 1, 2006
  9. J. Bruce FieldsJul 1, 2006
  10. Linus TorvaldsJul 1, 2006
  11. Daniel BarkalowJul 1, 2006
  12. Linus TorvaldsJul 1, 2006
  13. Daniel BarkalowJul 1, 2006
  14. Daniel BarkalowJul 1, 2006
  15. Rene ScharfeJul 2, 2006
  16. Daniel BarkalowJul 2, 2006
  17. Linus TorvaldsJul 2, 2006
  18. Jakub NarebskiJul 1, 2006
  19. Linus TorvaldsJul 1, 2006
  20. Junio C HamanoJul 1, 2006
  21. Rene ScharfeJul 1, 2006
  22. Junio C HamanoJul 1, 2006
  23. Johannes SchindelinJul 1, 2006
  24. Linus TorvaldsJul 1, 2006
  25. Junio C HamanoJul 1, 2006
  26. Junio C HamanoJul 1, 2006
  27. 1/3 Add get_merge_bases_clean()Rene Scharfe, Jul 1, 2006
  28. Johannes SchindelinJul 1, 2006
  29. 2/3 Add '...' operator for revisionsRene Scharfe, Jul 1, 2006
  30. 3/3 Make clear_commit_marks() clean harderRene Scharfe, Jul 1, 2006
  31. Junio C HamanoJul 3, 2006
  32. Johannes SchindelinJul 3, 2006
  33. Linus TorvaldsJul 3, 2006
  34. Johannes SchindelinJul 3, 2006
  35. Junio C HamanoJul 3, 2006
  36. Johannes SchindelinJul 3, 2006
  37. Linus TorvaldsJul 3, 2006
  38. Johannes SchindelinJul 4, 2006
  39. Junio C HamanoJul 4, 2006
  40. 4/3 Fold get_merge_bases_clean() into get_merge_bases()Rene Scharfe, Jul 2, 2006
  41. Johannes SchindelinJul 2, 2006
  42. Linus TorvaldsJul 2, 2006
  43. Rene ScharfeJul 2, 2006
  44. Junio C HamanoJul 2, 2006
  45. Rene ScharfeJul 2, 2006
  46. Rene ScharfeJul 2, 2006
  47. Linus TorvaldsJul 2, 2006
  48. Linus TorvaldsJul 2, 2006
  49. Junio C HamanoJul 7, 2006

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.