Thread (42 messages) 42 messages, 5 authors, 2019-01-16

Re: [PATCH v4 4/6] revision: implement sparse algorithm

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2018-12-17 14:26:26

On Mon, Dec 17 2018, Derrick Stolee wrote:
On 12/14/2018 6:32 PM, Ævar Arnfjörð Bjarmason wrote:
quoted
On Fri, Dec 14 2018, Derrick Stolee via GitGitGadget wrote:
quoted
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"?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help