Re: Merge after directory rename ?

From: Michael Witten <mfwitten@gmail.com>
Date: Aug 21, 2011, 23:45 UTC
Message-ID: <CAMOZ1BukGPZt8gJh0J4EHRrPHv5teAdnkNT+gZJa9mX=2ohFOw@mail.gmail.com>
In-Reply-To: <j2ru2h$cd$1@dough.gmane.org>

2011/8/21 Marcin Wiśnicki <mwisnicki@gmail.com>:

Show 14 quoted lines

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