On 5/1/08, Ittay Dror <ittayd@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
