From: Elijah Newren via GitGitGadget <hidden> Date: 2021-06-26 17:05:26
From: Elijah Newren <redacted>
Directory rename detection can cause transitive renames, e.g. if the two
different sides of history each do one half of:
A/file -> B/file
B/ -> C/
then directory rename detection transitively renames to give us C/file.
Since the default for merge.directoryRenames is conflict, this results
in an error message saying it is unclear whether the file should be
placed at B/file or C/file.
What if C/ is A/, though? In such a case, the transitive rename would
give us A/file, the original name we started with. Logically, having
an error message with B/file vs. A/file should be fine, as should
leaving the file where it started. But the logic in both
merge-recursive and merge-ort did not handle a case of a filename being
renamed to itself correctly; merge-recursive had two bugs, and merge-ort
had one. Add some testcases covering such a scenario.
Based-on-testcase-by: Anders Kaseorg [off-list ref]
Signed-off-by: Elijah Newren <redacted>
---
t/t6423-merge-rename-directories.sh | 117 ++++++++++++++++++++++++++++
1 file changed, 117 insertions(+)
From: Elijah Newren via GitGitGadget <hidden> Date: 2021-06-26 17:05:31
From: Elijah Newren <redacted>
Path conflicts (typically rename path conflicts, e.g.
rename/rename(1to2) or rename/add/delete), and directory/file conflicts
should obviously result in files not being marked as clean in the merge.
We had a codepath where we missed consulting the path_conflict and
df_conflict flags, based on match_mask. Granted, it requires an unusual
setup to trigger this codepath (directory rename causing rename-to-self
is the only case I can think of), but we still need to handle it. To
make it clear that we have audited the other codepaths that do not
explicitly mention these flags, add some assertions that the flags are
not set.
Reported-by: Anders Kaseorg <redacted>
Signed-off-by: Elijah Newren <redacted>
---
merge-ort.c | 6 +++++-
t/t6423-merge-rename-directories.sh | 4 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
From: Elijah Newren via GitGitGadget <hidden> Date: 2021-06-26 17:05:31
From: Elijah Newren <redacted>
Directory rename detection can cause transitive renames, e.g. if the two
different sides of history each do one half of:
A/file -> B/file
B/ -> C/
then directory rename detection transitively renames to give us
A/file -> C/file
However, when C/ == A/, note that this gives us
A/file -> A/file.
merge-recursive assumed that any rename D -> E would have D != E. While
that is almost always true, the above is a special case where it is not.
So we cannot do things like delete the rename source, we cannot assume
that a file existing at path E implies a rename/add conflict and we have
to be careful about what stages end up in the output.
This change feels a bit hackish. It took me surprisingly many hours to
find, and given merge-recursive's design causing it to attempt to
enumerate all combinations of edge and corner cases with special code
for each combination, I'm worried there are other similar fixes needed
elsewhere if we can just come up with the right special testcase.
Perhaps an audit would rule it out, but I have not the energy.
merge-recursive deserves to die, and since it is on its way out anyway,
fixing this particular bug narrowly will have to be good enough.
Reported-by: Anders Kaseorg <redacted>
Signed-off-by: Elijah Newren <redacted>
---
merge-recursive.c | 19 +++++++++++++------
t/t6423-merge-rename-directories.sh | 4 ++--
2 files changed, 15 insertions(+), 8 deletions(-)
@@ -2804,12 +2804,19 @@ static int process_renames(struct merge_options *opt,intrenamed_stage=a_renames==renames1?2:3;intother_stage=a_renames==renames1?3:2;+/*+*Directoryrenameshaveafunnycornercase...+*/+intrenamed_to_self=!strcmp(ren1_src,ren1_dst);+/* BUG: We should only remove ren1_src in the base*stageandinother_stage(thinkofrename+*add-sourcecase).*/-remove_file(opt,1,ren1_src,-renamed_stage==2||!was_tracked(opt,ren1_src));+if(!renamed_to_self)+remove_file(opt,1,ren1_src,+renamed_stage==2||+!was_tracked(opt,ren1_src));oidcpy(&src_other.oid,&ren1->src_entry->stages[other_stage].oid);
@@ -2823,6 +2830,9 @@ static int process_renames(struct merge_options *opt,ren1->dir_rename_original_type=='A'){setup_rename_conflict_info(RENAME_VIA_DIR,opt,ren1,NULL);+}elseif(renamed_to_self){+setup_rename_conflict_info(RENAME_NORMAL,+opt,ren1,NULL);}elseif(oideq(&src_other.oid,null_oid())){setup_rename_conflict_info(RENAME_DELETE,opt,ren1,NULL);
@@ -3180,7 +3190,6 @@ static int handle_rename_normal(struct merge_options *opt,structrename*ren=ci->ren1;structmerge_file_infomfi;intclean;-intside=(ren->branch==opt->branch1?2:3);/* Merge the content and write it out */clean=handle_content_merge(&mfi,opt,path,was_dirty(opt,path),
@@ -3190,9 +3199,7 @@ static int handle_rename_normal(struct merge_options *opt,opt->detect_directory_renames==MERGE_DIRECTORY_RENAMES_CONFLICT&&ren->dir_rename_original_dest){if(update_stages(opt,path,-NULL,-side==2?&mfi.blob:NULL,-side==2?NULL:&mfi.blob))+&mfi.blob,&mfi.blob,&mfi.blob))return-1;clean=0;/* not clean, but conflicted */}
From: Junio C Hamano <hidden> Date: 2021-06-29 04:02:49
"Elijah Newren via GitGitGadget" [off-list ref] writes:
From: Elijah Newren <redacted>
Directory rename detection can cause transitive renames, e.g. if the two
different sides of history each do one half of:
A/file -> B/file
B/ -> C/
then directory rename detection transitively renames to give us
A/file -> C/file
However, when C/ == A/, note that this gives us
A/file -> A/file.
Heh, of course this is recent because the "guess that directory B
has been moved to C in its entirety" heuristic is quite new.
Nicely fixed and described. Will queue. Thanks.
quoted hunk
merge-recursive assumed that any rename D -> E would have D != E. While
that is almost always true, the above is a special case where it is not.
So we cannot do things like delete the rename source, we cannot assume
that a file existing at path E implies a rename/add conflict and we have
to be careful about what stages end up in the output.
This change feels a bit hackish. It took me surprisingly many hours to
find, and given merge-recursive's design causing it to attempt to
enumerate all combinations of edge and corner cases with special code
for each combination, I'm worried there are other similar fixes needed
elsewhere if we can just come up with the right special testcase.
Perhaps an audit would rule it out, but I have not the energy.
merge-recursive deserves to die, and since it is on its way out anyway,
fixing this particular bug narrowly will have to be good enough.
Reported-by: Anders Kaseorg <redacted>
Signed-off-by: Elijah Newren <redacted>
---
merge-recursive.c | 19 +++++++++++++------
t/t6423-merge-rename-directories.sh | 4 ++--
2 files changed, 15 insertions(+), 8 deletions(-)
@@ -2804,12 +2804,19 @@ static int process_renames(struct merge_options *opt,intrenamed_stage=a_renames==renames1?2:3;intother_stage=a_renames==renames1?3:2;+/*+*Directoryrenameshaveafunnycornercase...+*/+intrenamed_to_self=!strcmp(ren1_src,ren1_dst);+/* BUG: We should only remove ren1_src in the base*stageandinother_stage(thinkofrename+*add-sourcecase).*/-remove_file(opt,1,ren1_src,-renamed_stage==2||!was_tracked(opt,ren1_src));+if(!renamed_to_self)+remove_file(opt,1,ren1_src,+renamed_stage==2||+!was_tracked(opt,ren1_src));oidcpy(&src_other.oid,&ren1->src_entry->stages[other_stage].oid);
@@ -2823,6 +2830,9 @@ static int process_renames(struct merge_options *opt,ren1->dir_rename_original_type=='A'){setup_rename_conflict_info(RENAME_VIA_DIR,opt,ren1,NULL);+}elseif(renamed_to_self){+setup_rename_conflict_info(RENAME_NORMAL,+opt,ren1,NULL);}elseif(oideq(&src_other.oid,null_oid())){setup_rename_conflict_info(RENAME_DELETE,opt,ren1,NULL);
@@ -3180,7 +3190,6 @@ static int handle_rename_normal(struct merge_options *opt,structrename*ren=ci->ren1;structmerge_file_infomfi;intclean;-intside=(ren->branch==opt->branch1?2:3);/* Merge the content and write it out */clean=handle_content_merge(&mfi,opt,path,was_dirty(opt,path),
@@ -3190,9 +3199,7 @@ static int handle_rename_normal(struct merge_options *opt,opt->detect_directory_renames==MERGE_DIRECTORY_RENAMES_CONFLICT&&ren->dir_rename_original_dest){if(update_stages(opt,path,-NULL,-side==2?&mfi.blob:NULL,-side==2?NULL:&mfi.blob))+&mfi.blob,&mfi.blob,&mfi.blob))return-1;clean=0;/* not clean, but conflicted */}
On 6/26/2021 1:05 PM, Elijah Newren via GitGitGadget wrote:
From: Elijah Newren <redacted>
Directory rename detection can cause transitive renames, e.g. if the two
different sides of history each do one half of:
A/file -> B/file
B/ -> C/
then directory rename detection transitively renames to give us C/file.
Since the default for merge.directoryRenames is conflict, this results
in an error message saying it is unclear whether the file should be
placed at B/file or C/file.
What if C/ is A/, though?
This case seems interesting, but somehow missing from the test cases
below. Each of those cases include renaming up or down the directory
hierarchy instead of doing a sideways rename.
+# Testcase 12i, Directory rename causes rename-to-self
+# Commit O: source/{subdir/foo, bar, baz_1}
+# Commit A: source/{foo, bar, baz_1}
+# Commit B: source/{subdir/{foo, bar}, baz_2}
+# Expected: source/{foo, bar, baz_2}, with conflicts on
+# source/bar vs. source/subdir/bar
This test goes deeper.
+# Testcase 12j, Directory rename to root causes rename-to-self
+# Commit O: {subdir/foo, bar, baz_1}
+# Commit A: {foo, bar, baz_1}
+# Commit B: {subdir/{foo, bar}, baz_2}
+# Expected: {foo, bar, baz_2}, with conflicts on bar vs. subdir/bar
This test goes higher.
Does the problematic case not hit when going out to the side, such
as "with conflicts on subdir/bar vs otherdir/bar"?
If so, then _maybe_ the commit message could indicate this is an
omission on purpose. If not, then maybe a third test should be
added?
Thanks,
-Stolee
"Elijah Newren via GitGitGadget" [off-list ref] writes:
quoted
From: Elijah Newren <redacted>
Directory rename detection can cause transitive renames, e.g. if the two
different sides of history each do one half of:
A/file -> B/file
B/ -> C/
then directory rename detection transitively renames to give us
A/file -> C/file
However, when C/ == A/, note that this gives us
A/file -> A/file.
Heh, of course this is recent because the "guess that directory B
has been moved to C in its entirety" heuristic is quite new.
Nicely fixed and described. Will queue. Thanks.
I agree that the fixes in patches 2 and 3 are rather clean. The
tests added in patch 1 provide significant confidence in the
result, though I had a minor question about a possible third
test case.
Seeing the solutions that make the two tests pass leaves me to
consider that the third test case is likely unnecessary, because
there is nothing special about how the directories are being
renamed that must be handled by the fix.
Thanks,
-Stolee
On Tue, Jun 29, 2021 at 5:50 AM Derrick Stolee [off-list ref] wrote:
On 6/26/2021 1:05 PM, Elijah Newren via GitGitGadget wrote:
quoted
From: Elijah Newren <redacted>
Directory rename detection can cause transitive renames, e.g. if the two
different sides of history each do one half of:
A/file -> B/file
B/ -> C/
then directory rename detection transitively renames to give us C/file.
Since the default for merge.directoryRenames is conflict, this results
in an error message saying it is unclear whether the file should be
placed at B/file or C/file.
What if C/ is A/, though?
This case seems interesting, but somehow missing from the test cases
below. Each of those cases include renaming up or down the directory
hierarchy instead of doing a sideways rename.
quoted
+# Testcase 12i, Directory rename causes rename-to-self
+# Commit O: source/{subdir/foo, bar, baz_1}
+# Commit A: source/{foo, bar, baz_1}
+# Commit B: source/{subdir/{foo, bar}, baz_2}
+# Expected: source/{foo, bar, baz_2}, with conflicts on
+# source/bar vs. source/subdir/bar
This test goes deeper.
quoted
+# Testcase 12j, Directory rename to root causes rename-to-self
+# Commit O: {subdir/foo, bar, baz_1}
+# Commit A: {foo, bar, baz_1}
+# Commit B: {subdir/{foo, bar}, baz_2}
+# Expected: {foo, bar, baz_2}, with conflicts on bar vs. subdir/bar
This test goes higher.
Does the problematic case not hit when going out to the side, such
as "with conflicts on subdir/bar vs otherdir/bar"?
If so, then _maybe_ the commit message could indicate this is an
omission on purpose. If not, then maybe a third test should be
added?
The only special case in the code is renaming to the root directory,
so I didn't think of extending beyond two cases. However, while
adding more testcases doesn't exercise the current incarnation of the
code further, it's pretty easy to add another and it certainly doesn't
hurt. I'll resubmit with a third testcase.
From: Elijah Newren via GitGitGadget <hidden> Date: 2021-06-30 17:30:07
From: Elijah Newren <redacted>
Directory rename detection can cause transitive renames, e.g. if the two
different sides of history each do one half of:
A/file -> B/file
B/ -> C/
then directory rename detection transitively renames to give us C/file.
Since the default for merge.directoryRenames is conflict, this results
in an error message saying it is unclear whether the file should be
placed at B/file or C/file.
What if C/ is A/, though? In such a case, the transitive rename would
give us A/file, the original name we started with. Logically, having
an error message with B/file vs. A/file should be fine, as should
leaving the file where it started. But the logic in both
merge-recursive and merge-ort did not handle a case of a filename being
renamed to itself correctly; merge-recursive had two bugs, and merge-ort
had one. Add some testcases covering such a scenario.
Based-on-testcase-by: Anders Kaseorg [off-list ref]
Signed-off-by: Elijah Newren <redacted>
---
t/t6423-merge-rename-directories.sh | 175 ++++++++++++++++++++++++++++
1 file changed, 175 insertions(+)
From: Elijah Newren via GitGitGadget <hidden> Date: 2021-06-30 17:30:08
From: Elijah Newren <redacted>
Path conflicts (typically rename path conflicts, e.g.
rename/rename(1to2) or rename/add/delete), and directory/file conflicts
should obviously result in files not being marked as clean in the merge.
We had a codepath where we missed consulting the path_conflict and
df_conflict flags, based on match_mask. Granted, it requires an unusual
setup to trigger this codepath (directory rename causing rename-to-self
is the only case I can think of), but we still need to handle it. To
make it clear that we have audited the other codepaths that do not
explicitly mention these flags, add some assertions that the flags are
not set.
Reported-by: Anders Kaseorg <redacted>
Signed-off-by: Elijah Newren <redacted>
---
merge-ort.c | 6 +++++-
t/t6423-merge-rename-directories.sh | 6 +++---
2 files changed, 8 insertions(+), 4 deletions(-)
From: Elijah Newren via GitGitGadget <hidden> Date: 2021-06-30 17:30:11
From: Elijah Newren <redacted>
Directory rename detection can cause transitive renames, e.g. if the two
different sides of history each do one half of:
A/file -> B/file
B/ -> C/
then directory rename detection transitively renames to give us
A/file -> C/file
However, when C/ == A/, note that this gives us
A/file -> A/file.
merge-recursive assumed that any rename D -> E would have D != E. While
that is almost always true, the above is a special case where it is not.
So we cannot do things like delete the rename source, we cannot assume
that a file existing at path E implies a rename/add conflict and we have
to be careful about what stages end up in the output.
This change feels a bit hackish. It took me surprisingly many hours to
find, and given merge-recursive's design causing it to attempt to
enumerate all combinations of edge and corner cases with special code
for each combination, I'm worried there are other similar fixes needed
elsewhere if we can just come up with the right special testcase.
Perhaps an audit would rule it out, but I have not the energy.
merge-recursive deserves to die, and since it is on its way out anyway,
fixing this particular bug narrowly will have to be good enough.
Reported-by: Anders Kaseorg <redacted>
Signed-off-by: Elijah Newren <redacted>
---
merge-recursive.c | 19 +++++++++++++------
t/t6423-merge-rename-directories.sh | 6 +++---
2 files changed, 16 insertions(+), 9 deletions(-)
@@ -2804,12 +2804,19 @@ static int process_renames(struct merge_options *opt,intrenamed_stage=a_renames==renames1?2:3;intother_stage=a_renames==renames1?3:2;+/*+*Directoryrenameshaveafunnycornercase...+*/+intrenamed_to_self=!strcmp(ren1_src,ren1_dst);+/* BUG: We should only remove ren1_src in the base*stageandinother_stage(thinkofrename+*add-sourcecase).*/-remove_file(opt,1,ren1_src,-renamed_stage==2||!was_tracked(opt,ren1_src));+if(!renamed_to_self)+remove_file(opt,1,ren1_src,+renamed_stage==2||+!was_tracked(opt,ren1_src));oidcpy(&src_other.oid,&ren1->src_entry->stages[other_stage].oid);
@@ -2823,6 +2830,9 @@ static int process_renames(struct merge_options *opt,ren1->dir_rename_original_type=='A'){setup_rename_conflict_info(RENAME_VIA_DIR,opt,ren1,NULL);+}elseif(renamed_to_self){+setup_rename_conflict_info(RENAME_NORMAL,+opt,ren1,NULL);}elseif(oideq(&src_other.oid,null_oid())){setup_rename_conflict_info(RENAME_DELETE,opt,ren1,NULL);
@@ -3180,7 +3190,6 @@ static int handle_rename_normal(struct merge_options *opt,structrename*ren=ci->ren1;structmerge_file_infomfi;intclean;-intside=(ren->branch==opt->branch1?2:3);/* Merge the content and write it out */clean=handle_content_merge(&mfi,opt,path,was_dirty(opt,path),
@@ -3190,9 +3199,7 @@ static int handle_rename_normal(struct merge_options *opt,opt->detect_directory_renames==MERGE_DIRECTORY_RENAMES_CONFLICT&&ren->dir_rename_original_dest){if(update_stages(opt,path,-NULL,-side==2?&mfi.blob:NULL,-side==2?NULL:&mfi.blob))+&mfi.blob,&mfi.blob,&mfi.blob))return-1;clean=0;/* not clean, but conflicted */}