From: David Lang <hidden> Date: 2016-06-15 22:43:01
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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:01
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
From: David Lang <hidden> Date: 2016-06-15 22:43:01
On Sun, 25 Mar 2007, Johannes Schindelin wrote:
On Sat, 24 Mar 2007, David Lang wrote:
quoted
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
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
From: David Lang <hidden> Date: 2016-06-15 22:43:01
On Sat, 24 Mar 2007, Linus Torvalds wrote:
On Sun, 25 Mar 2007, Johannes Schindelin wrote:
quoted
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