From: Junio C Hamano Date: Thu, 04 Feb 2010 00:48:20 GMT Subject: Re: git-mv redux: there must be something else going on Message-ID: <7vvded4yi3.fsf@alter.siamese.dyndns.org> In-Reply-To: Ron Garret 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.