From: Marcin Wiśnicki <hidden> Date: 2016-06-15 22:51:51
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.
From: Michael Witten <hidden> Date: 2016-06-15 22:51:51
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).
From: Michael Witten <hidden> Date: 2016-06-15 22:51:51
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.
From: Marcin Wiśnicki <hidden> Date: 2016-06-15 22:51:51
On Sun, 21 Aug 2011 23:53:34 +0000, Michael Witten wrote:
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,
I know it tracks content, yet it puts effort to detect file renames.
I want it to also detect directory renames, detecting it should be quite
easy.
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.
I would prefer it to be fully automatic :)
Or at least detect/warn about tree conflict.
Directory renames can happen quite frequently when working with Java/C#
and it is unreasonable to expect that lazy user will have to keep track of
it manually (with huge number of files it's impossible).
From: Michael Witten <hidden> Date: 2016-06-15 22:51:51
2011/8/22 Marcin Wiśnicki [off-list ref]:
On Sun, 21 Aug 2011 23:53:34 +0000, Michael Witten wrote:
quoted
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,
I know it tracks content, yet it puts effort to detect file renames.
I want it to also detect directory renames, detecting it should be quite
easy.
quoted
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.
I would prefer it to be fully automatic :)
I assume the smiley is tongue-in-cheek; however, in case it is not: It
can't be automatic in general; did my examples mean nothing?
Or at least detect/warn about tree conflict.
Did my examples mean nothing?
Directory renames can happen quite frequently when working with Java/C#
and it is unreasonable to expect that lazy user will have to keep track of
it manually (with huge number of files it's impossible).
Git doesn't know anything about Java/C#; that's the point.
In general, the user could make use of switches (as suggested). In
particular, perhaps there are merge hooks or merge drivers that could
be used or implemented for allowing a more environment-specific
handling of merges, a la GNU's ChangeLog merge driver:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob;f=lib/git-merge-changelog.c
Also, see the configuration section of `git help merge'. Also look at
the tool `git mergetool'.
From: Marcin Wiśnicki <hidden> Date: 2016-06-15 22:51:51
2011/8/22 Michael Witten [off-list ref]:
I assume the smiley is tongue-in-cheek; however, in case it is not: It
can't be automatic in general; did my examples mean nothing?
quoted
Or at least detect/warn about tree conflict.
Did my examples mean nothing?
Well kind of. Your example was different because you have created dir1
independently on branch1 and master in which case automatic rename
wouldn't be expected. If you would've created dir1 before branching
and renamed dir1 to dir3 (renamed all files under dir1) then I would
expect a rename while merging.
The exact behaviour of merging branch1 to master I want is:
let base = $(git merge-base master branch1)
for each {modified,added,deleted} file in $base..branch1:
let dir = $(dirname $file)
if $dir exists in master:
if $dir existed in $base: [1]
proceed
else: # both branches independently introduced same directory
tree conflict
else: # no $dir in master
if $dir existed in $base:
if all $dir/* files in $base..master were renamed to $newdir/*:
rename $file [s/$dir/$newdir/]
else: # $dir was removed
tree conflict
else:
proceed # simple addition
Where "$dir exists" means that a file with path of matching prefix exists.
By default tree conflict should be ignored (proceed with merge as
today) but user should be able to make it fatal.
[1] It would be better if instead of comparing two trees it would
analyze each commit independently to detect shadowed renames:
(dir1=>dir2 then new dir1) => still rename.
quoted
Directory renames can happen quite frequently when working with Java/C#
and it is unreasonable to expect that lazy user will have to keep track of
it manually (with huge number of files it's impossible).
Git doesn't know anything about Java/C#; that's the point.
And it shouldn't. Renames can happen with anything, I'm just pointing
out that they are quite frequent in Java/C#.
You might as well have a C project and rename directory "src" to
"sources" and, when merging branch created from before that, expect to
get automatic s/src/sources/.
In general, the user could make use of switches (as suggested). In
particular, perhaps there are merge hooks or merge drivers that could
be used or implemented for allowing a more environment-specific
handling of merges, a la GNU's ChangeLog merge driver:
Also, see the configuration section of `git help merge'. Also look at
the tool `git mergetool'.
Merge drivers are file type specific, mergetool is used to resolve
conflicts after merge and I don't see a pre-merge hook :(
From: Michael Witten <hidden> Date: 2016-06-15 22:51:52
2011/8/22 Marcin Wiśnicki [off-list ref]:
Well kind of. Your example was different because you have created dir1
independently on branch1 and master in which case automatic rename
wouldn't be expected. If you would've created dir1 before branching
and renamed dir1 to dir3 (renamed all files under dir1) then I would
expect a rename while merging.
I already covered this case in my initial paragraph. Good Luck!
From: Jeff King <hidden> Date: 2016-06-15 22:51:52
On Sun, Aug 21, 2011 at 11:53:34PM +0000, Michael Witten wrote:
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.