From: Junio C Hamano Date: Wed, 15 Feb 2006 09:54:52 GMT Subject: Re: Handling large files with GIT Message-ID: <7vd5hpj6ab.fsf@assigned-by-dhcp.cox.net> In-Reply-To: Linus Torvalds 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.