Re: Merge after directory rename ?

2011/8/21 Michael Witten [off-list ref]:

2011/8/21 Marcin Wiśnicki [off-list ref]:

quoted

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.