The problem is that if a file was replaced with a directory containing
another file with the same content and mode, an attempt to merge it
with a branch descended from a commit before this F->D transition will
cause merge-recursive to break. It breaks even if there were no
conflicting changes on that other branch.
Originally reported by Anders Melchiorsen.
Signed-off-by: Alex Riesen <redacted>
---
2009/5/11 Johannes Schindelin [off-list ref]:
Maybe you can turn this into a patch adding a test (with
test_expect_failure to mark it as a bug)? This would make debugging a lot
easier, as a non-installed Git could be tested.
Here.
t/t6020-merge-df.sh | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/t/t6020-merge-df.sh b/t/t6020-merge-df.sh
index a19d49d..b62b52a 100755
--- a/t/t6020-merge-df.sh
+++ b/t/t6020-merge-df.sh
@@ -22,4 +22,27 @@ git commit -m "File: dir"'
test_expect_code 1 'Merge with d/f conflicts' 'git merge "merge msg" B master'
+test_expect_failure 'F/D conflict' '
+ git reset --hard &&
+ git checkout master &&
+ rm .git/index &&
+
+ mkdir before &&
+ echo FILE >before/one &&
+ echo FILE >after &&
+ git add . &&
+ git commit -mfirst &&
+
+ rm -f after &&
+ git mv before after &&
+ git commit -mmove &&
+
+ git checkout -b para HEAD^ &&
+ echo COMPLETELY ANOTHER FILE >another &&
+ git add . &&
+ git commit -mpara &&
+
+ git merge master
+'
+
test_done
--
1.6.3.28.ga852b
Some path names which transitioned from file to a directory were not
updated in the final part of the merge (loop around unmerged entries in
merge_trees), because the branch in process_renames which filtered out
updates for the files with the same content ("merged same as existing")
has left the rename entry in processed state. In this case, the
processing cannot be finished at the process_renames phase (because
the old file still blocks creation of directory where new files should
appear), and must be postponed until the update_entry phase.
Signed-off-by: Alex Riesen <redacted>
---
Alex Riesen, Mon, May 11, 2009 11:42:17 +0200:The problem is that if a file was replaced with a directory containing
another file with the same content and mode, an attempt to merge it
with a branch descended from a commit before this F->D transition will
cause merge-recursive to break. It breaks even if there were no
conflicting changes on that other branch.
2009/5/11 Johannes Schindelin [off-list ref]:
quoted
Maybe you can turn this into a patch adding a test (with
test_expect_failure to mark it as a bug)? This would make debugging a lot
easier, as a non-installed Git could be tested.
Here.
t/t6020-merge-df.sh | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
Frankly, I'm not really sure. The solution came largely ... empirical
way. IOW, I tried more or less random things which looked like they
should fix the problem. So a review is very much appreciated. Please.
merge-recursive.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index a3721ef..3c5420b 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -980,14 +980,15 @@ static int process_renames(struct merge_options *o,
if (mfi.clean &&
sha_eq(mfi.sha, ren1->pair->two->sha1) &&
- mfi.mode == ren1->pair->two->mode)
+ mfi.mode == ren1->pair->two->mode) {
/*
* This messaged is part of
* t6022 test. If you change
* it update the test too.
*/
output(o, 3, "Skipped %s (merged same as existing)", ren1_dst);
- else {
+ ren1->dst_entry->processed = 0;
+ } else {
if (mfi.merge || !mfi.clean)
output(o, 1, "Renaming %s => %s", ren1_src, ren1_dst);
if (mfi.merge)--
1.6.3.28.ga852b
Hi,
On Mon, 11 May 2009, Alex Riesen wrote:
Some path names which transitioned from file to a directory were not
updated in the final part of the merge (loop around unmerged entries in
merge_trees), because the branch in process_renames which filtered out
updates for the files with the same content ("merged same as existing")
has left the rename entry in processed state. In this case, the
processing cannot be finished at the process_renames phase (because
the old file still blocks creation of directory where new files should
appear), and must be postponed until the update_entry phase.
I know that as a German, I am supposed to like long sentences and crowded
paragraphs. Maybe I am not that German after all.
Frankly, I'm not really sure. The solution came largely ... empirical
way. IOW, I tried more or less random things which looked like they
should fix the problem.
This does not give me the cozy feeling I need to review a patch. After
all, I do not want to do all the work that should be done by the patch
author, but I just want to put in my knowledge to verify that the patch
is correct.
But as you asked me explicitely...
quoted hunk
diff --git a/merge-recursive.c b/merge-recursive.c
index a3721ef..3c5420b 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -980,14 +980,15 @@ static int process_renames(struct merge_options *o,
if (mfi.clean &&
sha_eq(mfi.sha, ren1->pair->two->sha1) &&
- mfi.mode == ren1->pair->two->mode)
+ mfi.mode == ren1->pair->two->mode) {
/*
* This messaged is part of
* t6022 test. If you change
* it update the test too.
*/
output(o, 3, "Skipped %s (merged same as existing)", ren1_dst);
- else {
+ ren1->dst_entry->processed = 0;
+ } else {
So basically, you say that a dst_entry has not been processed, when it
_has_ been? That cannot be correct...
Ciao,
Dscho
2009/5/20 Johannes Schindelin [off-list ref]:
On Mon, 11 May 2009, Alex Riesen wrote:
quoted
Some path names which transitioned from file to a directory were not
updated in the final part of the merge (loop around unmerged entries in
merge_trees), because the branch in process_renames which filtered out
updates for the files with the same content ("merged same as existing")
has left the rename entry in processed state. In this case, the
processing cannot be finished at the process_renames phase (because
the old file still blocks creation of directory where new files should
appear), and must be postponed until the update_entry phase.
I know that as a German, I am supposed to like long sentences and crowded
paragraphs. Maybe I am not that German after all.
Will be shortened.
quoted
diff --git a/merge-recursive.c b/merge-recursive.c
index a3721ef..3c5420b 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -980,14 +980,15 @@ static int process_renames(struct merge_options *o,
if (mfi.clean &&
sha_eq(mfi.sha, ren1->pair->two->sha1) &&
- mfi.mode == ren1->pair->two->mode)
+ mfi.mode == ren1->pair->two->mode) {
/*
* This messaged is part of
* t6022 test. If you change
* it update the test too.
*/
output(o, 3, "Skipped %s (merged same as existing)", ren1_dst);
- else {
+ ren1->dst_entry->processed = 0;
+ } else {
So basically, you say that a dst_entry has not been processed, when it
_has_ been? That cannot be correct...
My feeling exactly. I'm afraid I just zeroed the effect of the branch
which should avoid rewriting of files with known same content.
It's just that the code has grown a little confusing...
I'm still thinking about how to avoid unneeded rewrites of the files
with same content under same name.