On 9/7/2018 1:15 PM, Jeff King wrote:
On Fri, Sep 07, 2018 at 05:23:31PM +0200, Ævar Arnfjörð Bjarmason wrote:
Hrm, no. I spoke too soon because I was conflating "commit-graph write"
v.s. "gc". For "gc" we're now with this change just e.g. spending 6
seconds on 2015-04-03-1M-git displaying
On Fri, Sep 07, 2018 at 05:23:31PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Hrm, no. I spoke too soon because I was conflating "commit-graph write"
> v.s. "gc". For "gc" we're now with this change just e.g. spending 6
> seconds on 2015-04-03-1M-git displaying nothing, because we're looping
>
On Fri, Sep 07 2018, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Sep 05 2018, Derrick Stolee wrote:
>
>> On 9/4/2018 6:07 PM, Junio C Hamano wrote:
>>> Ævar Arnfjörð Bjarmason writes:
>>>
With --stdin-packs we don't show any estimation of how much is left to
do. This is because we
On Wed, Sep 05 2018, Derrick Stolee wrote:
> On 9/4/2018 6:07 PM, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason writes:
>>
>>> With --stdin-packs we don't show any estimation of how much is left to
>>> do. This is because we might be processing more than one pack. We
>>> could be less lazy
On 9/7/2018 8:40 AM, Ævar Arnfjörð Bjarmason wrote:
On Tue, Sep 04 2018, Ævar Arnfjörð Bjarmason wrote:
Before this change the "commit-graph write" command didn't report any
progress. On my machine this command takes more than 10 seconds to
write the graph for linux.git, and around 1m30s on
On Tue, Sep 04 2018, Ævar Arnfjörð Bjarmason wrote:
> Before this change the "commit-graph write" command didn't report any
> progress. On my machine this command takes more than 10 seconds to
> write the graph for linux.git, and around 1m30s on the
> 2015-04-03-1M-git.git[1] test repository,
On 9/5/2018 5:46 PM, Junio C Hamano wrote:
Derrick Stolee writes:
for (i = 0; i < commits->nr; i++) {
+ display_progress(progress, i);
if (commits->list[i]->generation != GENERATION_NUMBER_INFINITY
&&
commits->list[i]->generation !=
Derrick Stolee writes:
>>> for (i = 0; i < commits->nr; i++) {
>>> + display_progress(progress, i);
>>> if (commits->list[i]->generation != GENERATION_NUMBER_INFINITY
>>> &&
>>> commits->list[i]->generation != GENERATION_NUMBER_ZERO)
>>>
On Wed, Sep 05 2018, Derrick Stolee wrote:
> On 9/4/2018 6:07 PM, Junio C Hamano wrote:
>> Ævar Arnfjörð Bjarmason writes:
>>
>>> With --stdin-packs we don't show any estimation of how much is left to
>>> do. This is because we might be processing more than one pack. We
>>> could be less lazy
On 9/4/2018 4:27 PM, Ævar Arnfjörð Bjarmason wrote:
@@ -591,8 +597,13 @@ static void close_reachable(struct packed_oid_list *oids)
{
int i;
struct commit *commit;
+ struct progress *progress = NULL;
+ int j = 0;
The change below over-counts the number of commits
On 9/4/2018 6:07 PM, Junio C Hamano wrote:
Ævar Arnfjörð Bjarmason writes:
With --stdin-packs we don't show any estimation of how much is left to
do. This is because we might be processing more than one pack. We
could be less lazy here and show progress, either detect by detecting
that we're
Ævar Arnfjörð Bjarmason writes:
> Before this change the "commit-graph write" command didn't report any
Please describe the pre-patch state in present tense without "Before
this change".
> progress. On my machine this command takes more than 10 seconds to
> write the graph for linux.git, and
On Tue, Sep 4, 2018 at 4:27 PM Ævar Arnfjörð Bjarmason wrote:
> With --stdin-packs we don't show any estimation of how much is left to
> do. This is because we might be processing more than one pack. We
> could be less lazy here and show progress, either detect by detecting
s/detect//
> that
Before this change the "commit-graph write" command didn't report any
progress. On my machine this command takes more than 10 seconds to
write the graph for linux.git, and around 1m30s on the
2015-04-03-1M-git.git[1] test repository, which is a test case for
larger monorepos.
Furthermore, since
14 matches
Mail list logo
