Avery Pennarun wrote:
Git already works fine for renames. The only situation where
something funny happens is if you rename a whole directory and someone
else creates a file in the old directory. (In that case, the new file
ends up in the old place instead of the new place.) However, even in
that case, there is still no conflict and no manual merging necessary.
Sorry, but this is not the situation as I have experienced it with a
local repository I have. I renamed a directory (without changing any
files in it). 'git diff <commit>^ <commit>' shows the rename fine, but
'git log -p -M -C <initial commit>..' does not (that is, the history for
files in that directory is shown from the rename commit only). Obviously
git-diff is not any better.
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). Also, what happens if I change the file in the new location and
someone else changes it in the old location? Will I need to do a manual
merge?
--
Ittay Dror <ittayd@xxxxxxxxxx>
Tikal <http://www.tikalk.com>
Tikal Project <http://tikal.sourceforge.net>
--
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
