Re: [PATCH v4 4/6] revision: implement sparse algorithm
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Dec 17, 2018, 14:50 UTC
- Message-ID
- <161dd748-2ba6-cac7-433e-bd493d429759@gmail.com>
- In-Reply-To
- <87a7l41b78.fsf@evledraar.gmail.com>
On 12/17/2018 9:26 AM, Ævar Arnfjörð Bjarmason wrote:
Show 10 quoted lines
> On Mon, Dec 17 2018, Derrick Stolee wrote: > > >> As for adding progress to this step, I'm open to it. It can be done as >> a sequel series. > Okey. To clarify I wasn't complaining about the lack of progress output, > we didn't have it before, just clarifying (as I've found out now) that > when you're talking about "enumerating objects" in your commit message > it's *not* what we're doing when we show the "Enumerating objects" > progress bar, but an unrelated step prior to that.
Part of the problem is that in builtin/pack-objects.c, we have the following:
if (progress)
progress_state = start_progress(_("Enumerating
objects"), 0);
if (!use_internal_rev_list)
read_object_list_from_stdin();
else {
get_object_list(rp.argc, rp.argv);
argv_array_clear(&rp);
}
cleanup_preferred_base();
if (include_tag && nr_result)
for_each_ref(add_ref_tag, NULL);
stop_progress(&progress_state);and the logic for walking uninteresting objects is the mark_edges_uninteresting() inside get_object_list() (both entirely contained in this progress state). Perhaps the best thing to do is to untangle the progress for the two modes based on 'use_internal_rev_list'. Could we then have the progress for get_object_list() be "Walking objects" instead?
Thanks, -Stolee