On 5/4/08, Ittay Dror <ittayd@xxxxxxxxxx> wrote: > 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 -- 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
