måndagen den 5 maj 2008 18.40.24 skrev Avery Pennarun: > 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. You will always find corner cases. Line-by line merge happens to work, not because it is the theoretically correct way, but because we have discovered that it nearly always works so our need for more specialized merging is not huge. We have also adapted our development practices to the way line-by-line merging works, i.e. we avoid binary files and funny text file formats. > 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. Sure, a merge that understands this is java and does the correct thing. Evn your case for C (with hypotetical directory rename detection) would fail if the renamed directory was used in an #include-statement (like #include <lib/foo.h>) Say someone thinks xxdiff should move to lib/xxdiff, while someone else adds a new reference to <xxdiff/xxdiff.h>. To resolve all cases you must have tools that understand what they are doing. Directyry rename detection only solves a few cases, but it may be easy enough to implement to warrant the effort to get the tick in the box. > > In neither case is it very much work to fix by hand, though :), I agree on that. -- robin -- 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
