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