From: Avery Pennarun Date: Thu, 01 May 2008 15:27:34 GMT Subject: Re: detecting rename->commit->modify->commit Message-ID: <32541b130805010827r22169651s37c707071f3448f2@mail.gmail.com> In-Reply-To: <4819D98E.1040004@tikalk.com> On 5/1/08, Ittay Dror wrote: > Also, would anyone like to comment on: > http://www.markshuttleworth.com/archives/123 (Renaming is > the killer app of distributed version control > )? 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