Re: merge renamed files/directories?

From: Jakub Narebski <jnareb@gmail.com>
Date: May 4, 2008, 09:34 UTC
Message-ID: <m3zlr65s6j.fsf@localhost.localdomain>
In-Reply-To: <481D52CC.1030503@tikalk.com>

Ittay Dror <ittayd@tikalk.com> writes:

> Avery Pennarun wrote:

Show 12 quoted lines

> > 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.

This is one thing where git differs from other SCMs. In "git log -- <path>" (that is what I assume you have used) the <path> argument is path limiter. It allows to specify more than one directory or a file.

Unfortunately currently "git log --follow=<file>" works only for single files, and doesn't yet work for directories; which is caused, among other things, by the lack of directory rename detection in git.

> [...] 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?

No, rename detection should make automatic merge possible.

-- 
Jakub Narebski
Poland
ShadeHawk on #git