* merge strategy request
@ 2007-03-24 22:46 David Lang
2007-03-25 1:20 ` Johannes Schindelin
0 siblings, 1 reply; 10+ messages in thread
From: David Lang @ 2007-03-24 22:46 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: merge strategy request
2007-03-25 1:20 ` Johannes Schindelin
@ 2007-03-25 1:18 ` David Lang
2007-03-25 4:31 ` Linus Torvalds
1 sibling, 0 replies; 10+ messages in thread
From: David Lang @ 2007-03-25 1:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
On Sun, 25 Mar 2007, Johannes Schindelin wrote:
> On Sat, 24 Mar 2007, David Lang wrote:
>
>> 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.
>
> 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.
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: merge strategy request
2007-03-24 22:46 merge strategy request David Lang
@ 2007-03-25 1:20 ` Johannes Schindelin
2007-03-25 1:18 ` David Lang
2007-03-25 4:31 ` Linus Torvalds
0 siblings, 2 replies; 10+ messages in thread
From: Johannes Schindelin @ 2007-03-25 1:20 UTC (permalink / raw)
To: David Lang; +Cc: git
Hi,
On Sat, 24 Mar 2007, David Lang wrote:
> 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.
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: merge strategy request
2007-03-25 1:20 ` Johannes Schindelin
2007-03-25 1:18 ` David Lang
@ 2007-03-25 4:31 ` Linus Torvalds
2007-03-25 6:25 ` David Lang
2007-03-25 7:17 ` Junio C Hamano
1 sibling, 2 replies; 10+ messages in thread
From: Linus Torvalds @ 2007-03-25 4:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Lang, git
On Sun, 25 Mar 2007, Johannes Schindelin wrote:
>
> Basically, just write a program named "git-merge-david-lang", which takes
> arguments of the form
>
> merge-base [merge-base2...] -- head remote [remote...]
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: merge strategy request
2007-03-25 4:31 ` Linus Torvalds
@ 2007-03-25 6:25 ` David Lang
2007-03-25 7:17 ` Junio C Hamano
1 sibling, 0 replies; 10+ messages in thread
From: David Lang @ 2007-03-25 6:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, git
On Sat, 24 Mar 2007, Linus Torvalds wrote:
> On Sun, 25 Mar 2007, Johannes Schindelin wrote:
>>
>> Basically, just write a program named "git-merge-david-lang", which takes
>> arguments of the form
>>
>> merge-base [merge-base2...] -- head remote [remote...]
>
> 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.
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: merge strategy request
2007-03-25 4:31 ` Linus Torvalds
2007-03-25 6:25 ` David Lang
@ 2007-03-25 7:17 ` Junio C Hamano
2007-03-25 23:34 ` Martin Langhoff
1 sibling, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2007-03-25 7:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, David Lang, git
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, 25 Mar 2007, Johannes Schindelin wrote:
>>
>> Basically, just write a program named "git-merge-david-lang", which takes
>> arguments of the form
>>
>> merge-base [merge-base2...] -- head remote [remote...]
>
> I think you are missing what David wants.
>
> David does *not* want a new global strategy. Adding those is fairly easy.
>
> David seems to 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
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: merge strategy request
2007-03-25 23:34 ` Martin Langhoff
@ 2007-03-25 23:16 ` David Lang
2007-03-25 23:44 ` Junio C Hamano
1 sibling, 0 replies; 10+ messages in thread
From: David Lang @ 2007-03-25 23:16 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, Linus Torvalds, Johannes Schindelin, git
On Mon, 26 Mar 2007, Martin Langhoff wrote:
> On 3/25/07, Junio C Hamano <junkio@cox.net> wrote:
>> 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.
>
> 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.
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: merge strategy request
2007-03-25 7:17 ` Junio C Hamano
@ 2007-03-25 23:34 ` Martin Langhoff
2007-03-25 23:16 ` David Lang
2007-03-25 23:44 ` Junio C Hamano
0 siblings, 2 replies; 10+ messages in thread
From: Martin Langhoff @ 2007-03-25 23:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Johannes Schindelin, David Lang, git
On 3/25/07, Junio C Hamano <junkio@cox.net> wrote:
> 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.
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: merge strategy request
2007-03-25 23:34 ` Martin Langhoff
2007-03-25 23:16 ` David Lang
@ 2007-03-25 23:44 ` Junio C Hamano
2007-03-26 0:11 ` Martin Langhoff
1 sibling, 1 reply; 10+ messages in thread
From: Junio C Hamano @ 2007-03-25 23:44 UTC (permalink / raw)
To: Martin Langhoff
Cc: Junio C Hamano, Linus Torvalds, Johannes Schindelin, David Lang,
git
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> 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 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 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.
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: merge strategy request
2007-03-25 23:44 ` Junio C Hamano
@ 2007-03-26 0:11 ` Martin Langhoff
0 siblings, 0 replies; 10+ messages in thread
From: Martin Langhoff @ 2007-03-26 0:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Johannes Schindelin, David Lang, git
On 3/26/07, Junio C Hamano <junkio@cox.net> wrote:
> 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.
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.
> 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.
That'd be great to have. How about both? ;-)
cheers,
m
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2007-03-26 0:13 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-03-24 22:46 merge strategy request David Lang
2007-03-25 1:20 ` Johannes Schindelin
2007-03-25 1:18 ` David Lang
2007-03-25 4:31 ` Linus Torvalds
2007-03-25 6:25 ` David Lang
2007-03-25 7:17 ` Junio C Hamano
2007-03-25 23:34 ` Martin Langhoff
2007-03-25 23:16 ` David Lang
2007-03-25 23:44 ` Junio C Hamano
2007-03-26 0:11 ` Martin Langhoff
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).