Re: detecting rename->commit->modify->commit

From: Avery Pennarun <apenwarr@gmail.com>
Date: May 1, 2008, 15:27 UTC
Message-ID: <32541b130805010827r22169651s37c707071f3448f2@mail.gmail.com>
In-Reply-To: <4819D98E.1040004@tikalk.com>

On 5/1/08, Ittay Dror <ittayd@tikalk.com> wrote:

> Also, would anyone like to comment on:
> http://www.markshuttleworth.com/archives/123 (Renaming is
> the killer app of distributed version control
> <http://www.markshuttleworth.com/archives/123>)?

One of the comments linked to this: http://automatthias.wordpress.com/2007/06/07/directory-renaming-in-scm/

Which points out that git doesn't really handle directory renames at all. If someone creates file A/X then renames A to B, then merges with someone who both added the file A/Y and modified A/X, git will produce a tree containing (modified) B/Y and (new) A/Y.

Technically this is "correct" in that no data is lost and there are no conflicts, but it is obviously not what was "intended", which was that the new file Y should have ended up in folder B.

Before you say this is not a realistic use case, I've personally had this exact problem:

- I had a project with all of my work in a folder "src"
- I decided that the 'src' folder was redundant, so I moved it all to
the root folder
- Someone else was working on an old maintenance branch which still had 'src'
- When I merged from that person, some new files were created under
'src', and of course didn't work.

Since the maintenance branch was long-lived, this problem happened repeatedly. That said, it's also pretty easy to work around, so it's not the end of the world.

Have fun,

Avery