From: Jakub Narebski <jnareb@gmail.com>
Date: Sun, 04 May 2008 09:34:23 GMT
Subject: Re: merge renamed files/directories?
Message-ID: <m3zlr65s6j.fsf@localhost.localdomain>
In-Reply-To: <481D52CC.1030503@tikalk.com>

Ittay Dror <ittayd@tikalk.com> writes:
> 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.

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