Ron Garret <ron1@xxxxxxxxxxx> 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. -- 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