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

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 4, 2010, 00:48 UTC
Message-ID: <7vvded4yi3.fsf@alter.siamese.dyndns.org>
In-Reply-To: <ron1-9FA846.14332803022010@news.gmane.org>

Ron Garret <ron1@flownet.com> writes:

Show 6 quoted lines

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