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
-
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