On Fri, Dec 14, 2018 at 1:31 PM Derrick Stolee wrote:
>
> Please double-check that you have the 'core.commitGraph' config setting
> enabled, or you will not read the commit-graph at run-time:
>
> git config core.commitGraph true
>
Yeah, this is what happens when trying too many things at onc
did hOn Fri, Dec 14, 2018 at 11:10 AM Bryan Turner
wrote:
>
> After you converted the repository from CVS to Git, did you run a manual
> repack?
>
> The process of converting a repository from another SCM often results
> in poor delta chain selections which result in a repository that's
> unneces
On Fri, Dec 14, 2018 at 2:48 PM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Fri, Dec 14 2018, Clement Moyroud wrote:
>
> > My group at work is migrating a CVS repo to Git. The biggest issue we
> > face so far is the performance of git blame, especially compared to
> > CVS on the same file. One file es
On Fri, Dec 14 2018, Clement Moyroud wrote:
> My group at work is migrating a CVS repo to Git. The biggest issue we
> face so far is the performance of git blame, especially compared to
> CVS on the same file. One file especially causes us trouble: it's a
> 30k lines file with 25 years of histor
On 12/14/2018 1:29 PM, Clement Moyroud wrote:
My group at work is migrating a CVS repo to Git. The biggest issue we
face so far is the performance of git blame, especially compared to
CVS on the same file. One file especially causes us trouble: it's a
30k lines file with 25 years of history in 3k
On Fri, Dec 14, 2018 at 10:29 AM Clement Moyroud
wrote:
>
> Hello,
>
> My group at work is migrating a CVS repo to Git. The biggest issue we
> face so far is the performance of git blame, especially compared to
> CVS on the same file. One file especially causes us trouble: it's a
> 30k lines file
Hello,
My group at work is migrating a CVS repo to Git. The biggest issue we
face so far is the performance of git blame, especially compared to
CVS on the same file. One file especially causes us trouble: it's a
30k lines file with 25 years of history in 3k+ commits. The complete
repo has 200k+ c
Michael Haggerty writes:
> The reason that cvs annotate is so much faster than git blame is that
> CVS stores revisions filewise, with all of the modifications to file
> $FILE being stored in a single $FILE,v file. So in the worst case, CVS
> only has to read this one file.
>
> Git, on the other
On 11/06/2015 02:37 PM, Jan Smets wrote:
> I have recently migrated a fairly large project from CVS to Git.
> One of the issues we're having is the blame/annotate performance.
> [...]
> cvs annotate of the same file (over the network) is ready in 0.8 seconds.
> blame/annotate is a frequently used o
Hi
I have recently migrated a fairly large project from CVS to Git.
One of the issues we're having is the blame/annotate performance.
The repository contains +650k commits total, of which ~300k are on
master. (raw size = ~8GB)
Running blame on one of the oldest files takes over 30 seconds.
Th
10 matches
Mail list logo
