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

["Avery Pennarun" <apenwarr@gmail.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