Re: [PATCH 0/2] Custom low-level merge driver support.

From: David Lang <david.lang@digitalinsight.com>
Date: Apr 18, 2007, 20:09 UTC
Message-ID: <Pine.LNX.4.63.0704181304220.2806@qynat.qvtvafvgr.pbz>
In-Reply-To: <alpine.LFD.0.98.0704181330050.2828@woody.linux-foundation.org>

On Wed, 18 Apr 2007, Linus Torvalds wrote:

Show 14 quoted lines

> On Wed, 18 Apr 2007, Junio C Hamano wrote:
>>
> So maybe each strategy could have "sub-strategies" for other file types.
>
> Ie something like
>
> 	[merge "ours"]
> 		name = pick our own version
> 		driver = /bin/true
> 		symlinks = /bin/true
>
> ie we'd use tyhe "driver" name for regular files, and the "symlinks" name
> for symlinks and if no "symlinks" entry exists, we error it out as a
> conflict?

this is starting to sound odd here.

we have .gitattributes define file types and what merge to use on those types

then we have this section define different merges to use on different file types.

I think that we would be better off defining a way for the existing type definitions to include the 'it's a symlink' type of info (and then deal with the merges from there) instead of spreading the tyep info among different sections.

I could see other applications careing if the thing being handed to it is a directory, or a named pipe, etc and wanting different rules for them (obviously this wouldn't be relavent for C source, but I think I could see it for other things)

I coudl also see having one external program that can handle the different types of files and/or merges. rather than having a different line for each would it make sense to add another variable that could be handed to the merge program that would tell it what sort of merge to do?

David Lang