From: Ittay Dror <ittayd@tikalk.com>
Date: Sun, 04 May 2008 06:08:12 GMT
Subject: Re: merge renamed files/directories?
Message-ID: <481D52CC.1030503@tikalk.com>
In-Reply-To: <32541b130805031111r4cbea8e1l19c34ac05016a89b@mail.gmail.com>



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@tikalk.com>
Tikal <http://www.tikalk.com>
Tikal Project <http://tikal.sourceforge.net>