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

["Avery Pennarun" <apenwarr@gmail.com>]

On 5/1/08, Jeff King <peff@peff.net> 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