Re: git-mv redux: there must be something else going on

Ron Garret [off-list ref] writes:

A and B start with a file named config.  A and B both make edits.  In 
addition, B renames config to be config1 and creates a new, very similar 
file called config2.  B then merges from A with the expectation that B's 
edits to config would end up in config1 and not config2.  It seems to me 
that without tracking renames, it would be luck of the draw which file 
the patch got applied to.

I don't think the above is necessarily "rename" issue, but touches an
interesting point -- it is so "interesting" to the point that no sane SCM
would even consider that is a problem they need to solve.

If config1 and config2 are about two different ways to configure the
software (e.g. two different build for different customers), and change
made by A was to accomodate new configuration option made in the upstream,
B might even want to have that addition reflected in _both_ of his
configuration files, config1 and config2.

Earlier in this message, I said that this is not an issue SCM should even
be solving, because a sane way to handle this would _not_ be to copy and
edit config1/config2 and keep track of them in SCM; instead, saner people
would maintain a build procedure (e.g. Makefile target) to transform the
template "config" into necessary "config1" and "config2" customized
variants.