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

Re: [PATCH] revision: introduce prepare_revision_walk_extended()

From
René Scharfe <l.s.r@web.de>
Date
Dec 18, 2017, 19:18 UTC
Message-ID
<39581cd0-0bfd-c8d1-642b-1245cf425ab4@web.de>
In-Reply-To
<20171218151043.GA9449@sigill.intra.peff.net>
Am 18.12.2017 um 16:10 schrieb Jeff King:
Show 17 quoted lines
> On Sat, Dec 16, 2017 at 01:12:16PM +0100, René Scharfe wrote:
> 
>> prepare_revision_walk() allows callers to take ownership of the array of
>> pending objects by setting the rev_info flag "leak_pending" and copying
>> the object_array "pending".  They use it to clear commit marks after
>> setup is done.  This interface is brittle enough that it requires
>> extensive comments.
>>
>> Provide an easier way by adding a function that can hand over the array
>> to a caller-supplied output parameter and converting all users of the
>> flag "leak_pending" to call prepare_revision_walk_extended() instead.
> 
> I think this is _better_, but it's still kind of a funny interface.
> 
> The root of the matter is that the revision-walking code doesn't clean
> up after itself. In every case, the caller is just saving these to clean
> up commit marks, isn't it?
bundle also checks if the pending objects exists.
Show 34 quoted lines
> Could we instead have an interface like:
> 
>    revs.clear_commit_marks = 1;
>    prepare_revision_walk(&revs);
>    ...
>    finish_revision_walk(&revs);
> 
> where that final function would do any cleanup, including clearing the
> commit marks. I suspect there are other small bits that get leaked
> because there's not really any "destructor" for a revision walk.
> 
> It's not as flexible as this whole "make a copy of the pending tips"
> thing, but it keeps all of the details abstracted away from the callers.
> 
> Alternatively:
> 
>> +`prepare_revision_walk_extended`::
>> +
>> +	Like prepare_revision_walk(), but allows callers to take ownership
>> +	of the array of pending objects by passing an object_array pointer
>> +	as the second parameter; passing NULL clears the array.
> 
> What if we just got rid of this function and had callers do:
> 
>    object_array_copy(&old_pending, &revs);
>    prepare_revision_walk(&revs);
>    ...
>    clear_commit_marks_for_object_array(&old_pending);
> 
> That sidesteps all of the memory ownership issues by just creating a
> copy. That's less efficient, but I'd be surprised if it matters in
> practice (we tend to do one or two revisions per process, there don't
> tend to be a lot of pending tips, and we're really just talking about
> copying some pointers here).
This was done before I added the leak_pending flag.

t5502 and t5571 have test cases with ca. 1000 pending objects, t5551 and t5541 with ca. 2000, p5310 more than 8000. That's just a few KB.

I don't know if there can be real-world use cases with millions of entries (when it would start to hurt).

Why does prepare_revision_walk() clear the list of pending objects at all? Assuming the list is append-only then perhaps remembering the last handled index would suffice.

René
Previous: Jeff KingNext: Jeff King
Message 4 of 32 in “revision: introduce prepare_revision_walk_extended()”
  1. revision: introduce prepare_revision_walk_extended()René Scharfe, Dec 16, 2017
  2. Martin ÅgrenDec 17, 2017
  3. Jeff KingDec 18, 2017
  4. René ScharfeDec 18, 2017
  5. Jeff KingDec 19, 2017
  6. Junio C HamanoDec 19, 2017
  7. Jeff KingDec 20, 2017
  8. René ScharfeDec 21, 2017
  9. Jeff KingDec 24, 2017
  10. René ScharfeDec 25, 2017
  11. 0/9 revision: get rid of the flag leak_pendingRené Scharfe, Dec 25, 2017
  12. 1/9 commit: avoid allocation in clear_commit_marks_many()René Scharfe, Dec 25, 2017
  13. Jeff KingJan 10, 2018
  14. 2/9 commit: use clear_commit_marks_many() in remove_redundant()René Scharfe, Dec 25, 2017
  15. 3/9 ref-filter: use clear_commit_marks_many() in do_merge_filter()René Scharfe, Dec 25, 2017
  16. 4/9 object: add clear_commit_marks_all()René Scharfe, Dec 25, 2017
  17. Jeff KingJan 10, 2018
  18. René ScharfeJan 11, 2018
  19. Jeff KingJan 12, 2018
  20. 5/9 bisect: avoid using the rev_info flag leak_pendingRené Scharfe, Dec 25, 2017
  21. Jeff KingJan 10, 2018
  22. René ScharfeJan 11, 2018
  23. Jeff KingJan 12, 2018
  24. 6/9 bundle: avoid using the rev_info flag leak_pendingRené Scharfe, Dec 25, 2017
  25. Junio C HamanoDec 28, 2017
  26. Jeff KingJan 10, 2018
  27. 7/9 checkout: avoid using the rev_info flag leak_pendingRené Scharfe, Dec 25, 2017
  28. Junio C HamanoDec 28, 2017
  29. 8/9 revision: remove the unused flag leak_pendingRené Scharfe, Dec 25, 2017
  30. 9/9 commit: remove unused function clear_commit_marks_for_object_array()René Scharfe, Dec 25, 2017
  31. Junio C HamanoDec 28, 2017
  32. Jeff KingJan 10, 2018

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.