On Wed, 18 Apr 2007, Linus Torvalds wrote:
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
-
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