On 5/1/08, Jeff King <peff@xxxxxxxx> wrote: > On Thu, May 01, 2008 at 11:27:34AM -0400, Avery Pennarun wrote: > > > 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. > > > Sure. But we've also had the exact case of: > > - there are some files in subdir/ [1], but that is not a good name, and > there is something else that you are going to add that would be > better named as subdir/. > - you rename subdir/ to bettername/ [2] > - you create subdir/newfile [3] > > but you _don't_ want newfile to go into bettername/. It's _replacing_ > what went into bettername/. I would argue that this is a sort of "directory splitting" operation. That is, all anyone ever did was add some files to a subdir/ that already existed [1], *or* move all the files from subdir/ to a previously-empty bettername/ [2], *or* create a new subdir/ and add files to it [3]. In each case, no merge operation was necessary and it is completely obvious by comparing "before and after" trees which case it was. I guess my argument here is just that it should be *possible* to deduce and implement both cases at merge time just fine using git's existing storage model. It just hasn't been implemented yet. (And incidentally, I think that's totally awesome and I'd never want to go back to an explicit rename tracking model.) I should shut up now because the actual merge machinery scares me and I'm not willing to volunteer to write a patch for this one :) 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
