Merge after directory rename ?

> Is it possible to merge files after performing directory renames in such
> way that new files will end up in renamed directories ?
>
> For example:
> 1. [master]  add dir1/file1
> 2. [branch1] branch from master
> 3. [branch1] add dir1/file2
> 4. [master]  rename dir1 to dir2
> 5. [master]  merge branch1
>
> Where it should notice that dir1=>dir2 and therefore {dir1=>dir2}/file2.
>
> Currently I end up with dir1/file2 which is undesirable as it breaks
> refactorings and requires a lot of manual effort to clean-up.

> 2011/8/21 Marcin Wiśnicki <mwisnicki@gmail.com>:
>> Is it possible to merge files after performing directory renames in such
>> way that new files will end up in renamed directories ?
>>
>> For example:
>> 1. [master]  add dir1/file1
>> 2. [branch1] branch from master
>> 3. [branch1] add dir1/file2
>> 4. [master]  rename dir1 to dir2
>> 5. [master]  merge branch1
>>
>> Where it should notice that dir1=>dir2 and therefore {dir1=>dir2}/file2.
>>
>> Currently I end up with dir1/file2 which is undesirable as it breaks
>> refactorings and requires a lot of manual effort to clean-up.
>
> Part of the assumption for someone working on `branch1' might be that
> `dir1/file2' is in fact in `dir1'. The rename via `master' conflicts
> with that assumption. In this case, a full-blown conflict might be
> useful.
>
> However, suppose that the author who is working with `master' doesn't
> need `dir1', but the author who is working with `branch1' does need it
> INDEPENDENTLY:
>
>  1. [master]  add dir2/file1
>  2. [branch1] branch from master
>  3. [branch1] add dir1/file2
>  4. [master]  add dir1/file3
>  5. [master]  rename dir1/file3 to dir3/file3
>  6. [master]  merge branch1
>
> In that case, you'd want `dir1/file2' from the `branch1' work to be
> silently created rather than automatically renamed to `dir3/file3'.
> This should not result in a conflict or a rename.
>
> So, from your grievance, I suppose that git currently assumes the
> latter case (and hence, gives no indication of a possible conflict).
> Perhaps git could be improved here at least in terms of a warning.
> Perhaps the merger could request that directory renames be considered
> conflicts or enforced, but this would have to involve the intent of
> the merger me thinks (using command line flags).

> Importantly, note that I used only file names in my example,
> specifically:
> 
>   5. [master]  rename dir1/file3 to dir3/file3
> 
> rather than mirroring your example by writing:
> 
>   5. [master]  rename dir1 to dir3
> 
> This is because git fundamentally tracks content, and paths are just one
> kind of content associated with another blob of content. Consequently,

> git really knows next to nothing about directories, so it's not too
> surprising that git doesn't bother finding such a DIRECTORY rename
> anyway (at most, git would detect a FILE rename, and your FILE
> `dir1/file2' has nothing to do with, say, the FILE `dir1/file1' being
> renamed `dir2/file1').
> 
> Still, some command line switches could be useful to help the user
> express to git what should be going on in a case such as yours.

> On Sun, 21 Aug 2011 23:53:34 +0000, Michael Witten wrote:
>> Importantly, note that I used only file names in my example,
>> specifically:
>>
>>   5. [master]  rename dir1/file3 to dir3/file3
>>
>> rather than mirroring your example by writing:
>>
>>   5. [master]  rename dir1 to dir3
>>
>> This is because git fundamentally tracks content, and paths are just one
>> kind of content associated with another blob of content. Consequently,
>
> I know it tracks content, yet it puts effort to detect file renames.
> I want it to also detect directory renames, detecting it should be quite
> easy.
>
>> git really knows next to nothing about directories, so it's not too
>> surprising that git doesn't bother finding such a DIRECTORY rename
>> anyway (at most, git would detect a FILE rename, and your FILE
>> `dir1/file2' has nothing to do with, say, the FILE `dir1/file1' being
>> renamed `dir2/file1').
>>
>> Still, some command line switches could be useful to help the user
>> express to git what should be going on in a case such as yours.
>
> I would prefer it to be fully automatic :)

> I assume the smiley is tongue-in-cheek; however, in case it is not: It
> can't be automatic in general; did my examples mean nothing?
>
>> Or at least detect/warn about tree conflict.
>
> Did my examples mean nothing?

>
>> Directory renames can happen quite frequently when working with Java/C#
>> and it is unreasonable to expect that lazy user will have to keep track of
>> it manually (with huge number of files it's impossible).
>
> Git doesn't know anything about Java/C#; that's the point.

> In general, the user could make use of switches (as suggested). In
> particular, perhaps there are merge hooks or merge drivers that could
> be used or implemented for allowing a more environment-specific
> handling of merges, a la GNU's ChangeLog merge driver:
> Also, see the configuration section of `git help merge'. Also look at
> the tool `git mergetool'.
>

> Well kind of. Your example was different because you have created dir1
> independently on branch1 and master in which case automatic rename
> wouldn't be expected. If you would've created dir1 before branching
> and renamed dir1 to dir3 (renamed all files under dir1) then I would
> expect a rename while merging.

> This is because git fundamentally tracks content, and paths are just
> one kind of content associated with another blob of content.
> Consequently, git really knows next to nothing about directories, so
> it's not too surprising that git doesn't bother finding such a
> DIRECTORY rename anyway (at most, git would detect a FILE rename, and
> your FILE `dir1/file2' has nothing to do with, say, the FILE
> `dir1/file1' being renamed `dir2/file1').
> 
> Still, some command line switches could be useful to help the user
> express to git what should be going on in a case such as yours.