Re: Handling large files with GIT

From: Junio C Hamano <junkio@cox.net>
Date: Feb 15, 2006, 09:54 UTC
Message-ID: <7vd5hpj6ab.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0602141953081.3691@g5.osdl.org>

Linus Torvalds <torvalds@osdl.org> writes:

> As far as I can tell, the output from git-merge-tree with that fix to only 
> simplify subdirectories that match exactly in all of base/branch1/branch2 
> is precisely the output that git-merge-recursive actually wants.

The matches the recollection I had last time I mucked with the code. Currently it is set up to do one path at a time in both index and working tree, so it would not be a trivial rewrite, but merge-tree based approach would speed things up quite a bit.

I was thinking about implementing mergers as a pipeline:

	git-merge-tree O A B |
        git-merge-renaming A |
        git-merge-aggressive A |
        git-merge-filemerge

git-merge-tree (yours) does not do trivial collapsing, and produce raw-diff from A. git-merge-renaming reads it, finds copied/renamed entries (maybe reusing parts of diffcore), and writes out the results in the same format as merge-tree output (that's why I am giving A on the command line -- so it can also read A if it wanted to. it may need to talk about what a path in A was even when merge-tree did not say anything about that path). Then git-merge-aggressive (bad naming, I know, it only corresponds to the flag of the same name in read-tree) will collapse git-merge-one-file equivalent stage collapsing. The remainder is fed to file-level merger for postprocessing. Everything except the last step would work on a data format that merge-tree outputs.