Re: [PATCH 00/14] Serialized Commit Graph

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Thu, Jan 25 2018, Derrick Stolee jotted:

> On 1/25/2018 10:46 AM, Ævar Arnfjörð Bjarmason wrote:
>> On Thu, Jan 25 2018, Derrick Stolee jotted:
>>
>>> * 'git log --topo-order -1000' walks all reachable commits to avoid
>>>    incorrect topological orders, but only needs the commit message for
>>>    the top 1000 commits.
>>>
>>> * 'git merge-base <A> <B>' may walk many commits to find the correct
>>>    boundary between the commits reachable from A and those reachable
>>>    from B. No commit messages are needed.
>>>
>>> * 'git branch -vv' checks ahead/behind status for all local branches
>>>    compared to their upstream remote branches. This is essentially as
>>>    hard as computing merge bases for each.
>> This is great, spotted / questions so far:
>>
>> * git graph --blah says you need to enable the config, should say
>>    "unknown option --blah <help>". I.e. overzelous config guard.
>
> This is a good point.
>
>> * On a big repo (git show-ref -s | ~/g/git/git-graph --write
>>    --update-head) is as of writing this still hanging for me, but strace
>>    shows it's brk()-ing. Presumably just still busy, a progress bar would
>>    be very nice.
>
> Oops! This is my mistake. The correct command should be:
>
>  git show-ref -s | git graph --write --update-head --stdin-commits
>
> Without "--stdin-commits" the command will walk all packed objects
> to look for commits and then build the graph. That's why it's taking
> so long. That method takes several minutes on the Linux repo, but with
> --stdin-commits it should take as long as "git log >/dev/null".

Thanks, it took around 15m to finish with the command I initially ran on
my test repo.

Then the `merge-base --is-ancestor` performance problem I was
complaining about in
https://public-inbox.org/git/87608bawoa.fsf@evledraar.gmail.com/ takes
around 1s with your series, 5s without it. Nice.