Re: A better approach to diffing and merging

From: Miklos Vajna <vmiklos@frugalware.org>
Date: Nov 30, 2008, 02:54 UTC
Message-ID: <20081130025408.GO19355@genesis.frugalware.org>
In-Reply-To: <200811291740.06865.bss03@volumehost.net>

On Sat, Nov 29, 2008 at 05:40:02PM -0600, "Boyd Stephen Smith Jr." <bss03@volumehost.net> wrote:

Show 12 quoted lines

> You might look deeper into Darcs development.  This level of 
> pluggable "understanding" of the file(s) being modified fits in well with a 
> Grand Unified Theory of Patching.  Also "understanding" patches better allows 
> Darcs to reorder patches (and calculate "reverse patches") better -- reducing 
> the time to do existing automatic merging (or reject the merge as 
> non-automatable) and make merges automatic that are currently not handled 
> automatically.
> 
> I'm not going to come out and discourage you or other from adding the 
> functionality to git, but I think there are more useful and practical ways to 
> improve git.  (Line-by-line merging is generally "good enough", the worst 
> enemy of "good" software.)

I think this was already discussed:

http://thread.gmane.org/gmane.comp.version-control.git/60457/focus=60512

If you mean just looking at the code moves/copies between the trees (but no other history), then a merge strategy which makes use of git blame's code move/copy detection would be indeed nice, though nobody created it so far.