merge strategy request

having just gone through a painful manual mere with a config file on a gentoo system (not useing git) it seems to me that there should be a better way to deal with merging config file updates. I know that gentoo doesn't use git for it's config files, but I don't think that git would do a whole lot better currently (but with access to the history, I think it could)

what's happening is

A---B
      \
   C---D

where A and C are the distro maintained config files, B is the one customized for the local system, and D needs to be basicly the same as B, but accounting for the changes between A and C

issues that I see (there are probably others)

1. blank lines and comments are 'uninteresting' changes in that they don't 
affect the result, so if they get botched slightly it doesn't result in a broken 
systems (although it can cause confusion), what's important are changes ourside 
the comments. this is especially critical if the version in B strips out 
comments compared to the sample version in A

2. if B changes a config option and C doesn't (compared to A) then you want to 
go with what's in B

3. for most config files the order of the options doesn't matter, so look for 
the same option name out of order.

4. for some config files there are groupings in the config (tags nested inside 
other tags), the nesting is important, even if the order isn't. frequently this 
nesting is indicated by whitespace indentation  (or if it's an XML-like config 
file the nesting can be determined directly from the tags) figuring out exactly 
waht strategy to use here could be a case of 'try several and see which one 
makes sense), or it could be that the user needs to identify the strategy to use 
for a particular file.

there's been talk about custom merge strategies for different types of files (uncompressing office documents to merge them for example), so I think this is along the same lines and wanted to let other people start thinking about the problem and possible solutions.

David Lang

Hi,

On Sat, 24 Mar 2007, David Lang wrote:

There is a nice example script, named git-merge-stupid, which you can use as template.

Basically, just write a program named "git-merge-david-lang", which takes arguments of the form

	merge-base [merge-base2...] -- head remote [remote...]

IOW, all arguments up to "--" are merge bases, and after the "--" comes the HEAD and all branches to be merged. All of these argument (except "--") are given as commit hashes.

IIRC, if no merge bases are passed, the program is expected to find out (basically, take the output of "git-merge-base --all <head> <remote>...").

And I really prefer _you_ working on it.

Ciao, Dscho

On Sun, 25 Mar 2007, Johannes Schindelin wrote:

I'll add it to my backlog of projects that I'd like to do someday ;-)

unfortunantly it's not likely to be anytime soon (too many things on the list ahead of it)

David Lang

On Sun, 25 Mar 2007, Johannes Schindelin wrote:

I think you are missing what David wants.

David does *not* want a new global strategy. Adding those is fairly easy.

David seem sto want a new per-file merge strategy, with the bog-standard recursive merge. We've talked about that possibility in the past, but we don't do it now. We always end up doing just the three-way merge.

		Linus

On Sat, 24 Mar 2007, Linus Torvalds wrote:

right, I can see ways to further improve the merge for config files, but they wouldn't applty to most other types of files, so it would require support for per file merge options.

others have requested this in the past, this is just one more way that per-file merge options would be useful.

David Lang

Linus Torvalds <torvalds@linux-foundation.org> writes:

Right. In the current system, git-mergetool might be a better place to add support for special perpose 3-version file-level merge backend than merge-recursive, at least until gitattributes materializes.

On 3/25/07, Junio C Hamano <junkio@cox.net> wrote:

Would it be possible to have an env var (GIT_MERGE) that can be used to call an arbitrary script with merge/diff3 semantics instead of using the internal 3-way merge? That way we could do syntax-specific merges (ignore comments/whitespace, for example).

i would surely have a use for it, as sometimes my internal team is not _that_ good about trimming whitespace, and we have merges that succeed except for their whitespace conflicts.

cheers,

martin

On Mon, 26 Mar 2007, Martin Langhoff wrote:

would you really want that for _all_ merges, or only for merges of specific file types?

if you want it for all merges you should be able to create a modified version of the current merge and just substatute it in your install.

if you want it only for specific file types (say .c, .h, and .cfg files) then you really want the gitattributes support.

did anyone jump in on that for a soc project?

David Lang

"Martin Langhoff" <martin.langhoff@gmail.com> writes:

I do not think such a patch is hard, as calling external merge for file-level merge is what we used to do. It's just a matter of resurrecting the code we threw away and making it be called conditionally.

But a more interesting point is "under what condition". If the condition is "when GIT_MERGE environment is defined", it is not much better than what Dscho suggested, as the external merger would be called for all paths. We would want a mechanism to decide use of such a specialized merge backend for special cases, which is where gitattributes comes into the picture. Especially because there would be one specialized to merge xml documents, one to merge gimp xcf files, and another to merge gentoo configuration files (or whatever the original thread starter wanted).

I know Linus does not like applying patches with whitespace fuzziness, but I personally think a merge that ignores whitespace changes would be a useful thing to have, without having to call an external specialized merge backend. In other words, I do not think it is so special a thing to want to, but it is rather an unfortunate norm. I am not opposed to give git-merge-recursive a command line option to tell it to merge ignoring the whitespace-only changes, when it does the 3-way file-level merge internally.

There is a small detail of how to pass such a command line option to git-merge-$strategy backends, though.

On 3/26/07, Junio C Hamano <junkio@cox.net> wrote:

Well well... no. Unless you mean all paths that need diff3 merging (that is, all paths that changed on both sides). And in that case, the script itself can have the "change policy depending on file extension or phase of the moon" machinery. I think it makes it more powerful because it can have specialised logic for this -- where the git machinery is going to be limited to simpler rules (like file extension).

In any case, it is a _different_ mechanism to saying "all changed paths on either side". I don't know if there is even an interesting case for that.

That'd be great to have. How about both? ;-)

cheers,

m