Re: Performance issue exposed by git-filter-branch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The thread titled "git and larger trees, not so fast?".  Some of the history is lost, but here's the earliest post I can find:

http://lists-archives.org/git/627040-git-and-larger-trees-not-so-fast.html

On GMANE:
http://article.gmane.org/gmane.comp.version-control.git/55460/match=git+larger+trees+not+so+fast

But I can't figure out how to show the whole thread.

Sorry, that paragraph of my email disappeared. :-(

Ken

On Dec 16, 2010, at 5:45 PM, Jonathan Nieder wrote:

> Hi Ken,
> 
> Ken Brownfield wrote:
> 
>> Is there a way to apply the optimizations mentioned in that old
>> thread to the code paths used by git-filter-branch (mainly git-read
>> and git-rm, seemingly), or is there another way to investigate and
>> improve the performance of the filter?
> 
> Which old thread?
> 
> You might be able to get faster results using the approach of [1]
> (using "git cat-file --batch-check" to collect the trees you want
> and "git fast-import" to paste them together), which avoids unpacking
> trees when not needed.
> 
> Hope that helps,
> Jonathan
> 
> [1] http://repo.or.cz/w/git/barrbrain/github.git/commitdiff/db-svn-filter-root

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]