Re: merge renamed files/directories?

From: Avery Pennarun <apenwarr@gmail.com>
Date: May 5, 2008, 16:40 UTC
Message-ID: <32541b130805050940x1297e907ofc67ee65494897eb@mail.gmail.com>
In-Reply-To: <481D52CC.1030503@tikalk.com>

On 5/4/08, Ittay Dror <ittayd@tikalk.com> wrote:

Show 9 quoted lines

>  Avery Pennarun wrote:
> > In fact, as someone else pointed out, renaming a java file requires
> > you to modify the file anyhow, so having git auto-move the file to
> > another directory *still* wouldn't make it work any better.
>
> Sure it will, because otherwise I need to move it and still need to fix it.
> And there are many other file formats and languages where such a move will
> not require any change (I think it is funny that Java is a justification for
> not doing something for a tool primarily used by C people).

I mentioned Java because you mentioned you were working in java.

The particular problem with Java doesn't happen to C people. Imagine, for example, that I add a new file, lib/foo.c, to lib/lib.a (thus they have to modify lib/Makefile), while someone else renames "lib" to "bettername".

When I merge, if git would create bettername/foo.c (it currently
won't) and properly automerge bettername/Makefile (it will), then the
program would still compile correctly.  However this doesn't work in
Java: lib/foo.java would include the word "lib" in its contents (in
the namespace declaration) and so there's no way automatic merging
would have resulted in a version that compiles correctly.

So what I said isn't to *justify* git's behaviour, merely to point out that in java's case, there seems to be no way to get fully automatic merging that would work. In C, this case would have worked, if only git supported directory renames.

In neither case is it very much work to fix by hand, though :)

Have fun,

Avery