2011/8/21 Michael Witten <mfwitten@xxxxxxxxx>:
> 2011/8/21 Marcin Wiśnicki <mwisnicki@xxxxxxxxx>:
>> 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.
--
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