Re: Merge after directory rename ?

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

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).