On Mon, Dec 17 2018, Derrick Stolee wrote: > On 12/14/2018 6:32 PM, Ævar Arnfjörð Bjarmason wrote: >> On Fri, Dec 14 2018, Derrick Stolee via GitGitGadget wrote: >> >>> Despite these potential drawbacks, the benefits of the algorithm >>> are clear. By adding a counter to 'add_children_by_path' and >>> 'mark_tree_contents_uninteresting', I measured the number of >>> parsed trees for the two algorithms in a variety of repos. >> We spend a long time printing those out before we ever get to >> "Enumerating objects". >> >> Which was where I was trying to test this, i.e. is this a lot of work we >> perform before we print out the progress bar, and regardless of this >> optimization should have other progress output there, so we can see this >> time we're spending on this? > > It is true that part of the problem is that a 'git push' will sit for > a while without presenting any feedback until this part of the > algorithm is complete. The current series intends to significantly > reduce this time. > 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. I thought I might have been holding this wrong. > What would we use to describe this section? "Enumerating remote > objects"? Isn't this "Discovering objects to push to remote" i.e. "Selecting objects", but then what's "Enumerating objects" really doing? "Looping over objects we selected before and creating a pack"?
