From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: [PATCH] merge-recursive: add/add really is modify/modify with an empty base
Date: Wed, 13 Dec 2006 04:05:39 +0100 (CET) [thread overview]
Message-ID: <Pine.LNX.4.63.0612130402300.2807@wbgn013.biozentrum.uni-wuerzburg.de> (raw)
In-Reply-To: <7vvekgog0r.fsf@assigned-by-dhcp.cox.net>
Unify the handling for cases C (add/add) and D (modify/modify).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Tue, 12 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > How about this: if there is an add/add conflict, we treat it
> > as if there _was_ an empty file, and we let the shiny new
> > xdl_merge() find the _true_ conflicts, _instead of_ removing
> > the file from the index, adding both files with different
> > "~blabla" markers appended to their file names to the working
> > directory.
>
> I was not thinking about this t6024 test failure problem but was
> wondering about doing exactly that in merge-recursive to match
> the "two file merge" magic we have in git-merge-one-file.sh
As can be seen with the test case, the result is more pleasing.
merge-recursive.c | 44 +++++++++++++++-----------------------------
t/t6024-recursive-merge.sh | 12 +++++++++++-
2 files changed, 26 insertions(+), 30 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 7d203a6..5bec599 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -610,6 +610,12 @@ static void fill_mm(const unsigned char *sha1, mmfile_t *mm)
unsigned long size;
char type[20];
+ if (!hashcmp(sha1, null_sha1)) {
+ mm->ptr = xstrdup("");
+ mm->size = 0;
+ return;
+ }
+
mm->ptr = read_sha1_file(sha1, type, &size);
if (!mm->ptr || strcmp(type, blob_type))
die("unable to read blob object %s", sha1_to_hex(sha1));
@@ -1045,38 +1051,17 @@ static int process_entry(const char *path, struct stage_data *entry,
output("Adding %s", path);
update_file(1, sha, mode, path);
}
- } else if (!o_sha && a_sha && b_sha) {
- /* Case C: Added in both (check for same permissions). */
- if (sha_eq(a_sha, b_sha)) {
- if (a_mode != b_mode) {
- clean_merge = 0;
- output("CONFLICT: File %s added identically in both branches, "
- "but permissions conflict %06o->%06o",
- path, a_mode, b_mode);
- output("CONFLICT: adding with permission: %06o", a_mode);
- update_file(0, a_sha, a_mode, path);
- } else {
- /* This case is handled by git-read-tree */
- assert(0 && "This case must be handled by git-read-tree");
- }
- } else {
- const char *new_path1, *new_path2;
- clean_merge = 0;
- new_path1 = unique_path(path, branch1);
- new_path2 = unique_path(path, branch2);
- output("CONFLICT (add/add): File %s added non-identically "
- "in both branches. Adding as %s and %s instead.",
- path, new_path1, new_path2);
- remove_file(0, path, 0);
- update_file(0, a_sha, a_mode, new_path1);
- update_file(0, b_sha, b_mode, new_path2);
- }
-
- } else if (o_sha && a_sha && b_sha) {
+ } else if (a_sha && b_sha) {
+ /* Case C: Added in both (check for same permissions) and */
/* case D: Modified in both, but differently. */
+ const char *reason = "content";
struct merge_file_info mfi;
struct diff_filespec o, a, b;
+ if (!o_sha) {
+ reason = "add/add";
+ o_sha = (unsigned char *)null_sha1;
+ }
output("Auto-merging %s", path);
o.path = a.path = b.path = (char *)path;
hashcpy(o.sha1, o_sha);
@@ -1093,7 +1078,8 @@ static int process_entry(const char *path, struct stage_data *entry,
update_file(1, mfi.sha, mfi.mode, path);
else {
clean_merge = 0;
- output("CONFLICT (content): Merge conflict in %s", path);
+ output("CONFLICT (%s): Merge conflict in %s",
+ reason, path);
if (index_only)
update_file(0, mfi.sha, mfi.mode, path);
diff --git a/t/t6024-recursive-merge.sh b/t/t6024-recursive-merge.sh
index 9416c27..964010e 100644
--- a/t/t6024-recursive-merge.sh
+++ b/t/t6024-recursive-merge.sh
@@ -58,9 +58,19 @@ GIT_AUTHOR_DATE="2006-12-12 23:00:08" git commit -m F
test_expect_failure "combined merge conflicts" "git merge -m final G"
+cat > expect << EOF
+<<<<<<< HEAD/a1
+F
+=======
+G
+>>>>>>> 26f86b677eb03d4d956dbe108b29cb77061c1e73/a1
+EOF
+
+test_expect_success "result contains a conflict" "diff -u expect a1"
+
git ls-files --stage > out
cat > expect << EOF
-100644 f70f10e4db19068f79bc43844b49f3eece45c4e8 1 a1
+100644 f16f906ab60483c100d1241dfc39868de9ec9fcb 1 a1
100644 cf84443e49e1b366fac938711ddf4be2d4d1d9e9 2 a1
100644 fd7923529855d0b274795ae3349c5e0438333979 3 a1
EOF
--
next prev parent reply other threads:[~2006-12-13 3:05 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-07 10:17 [PATCH 1/1] Make sure the empty tree exists when needed in merge-recursive Shawn O. Pearce
2006-12-09 23:55 ` [PATCH 1/3] diff_tree_sha1(): avoid rereading trees if possible Johannes Schindelin
2006-12-10 1:47 ` Junio C Hamano
2006-12-10 22:49 ` Johannes Schindelin
2006-12-09 23:56 ` [PATCH 2/3] merge-recursive: make empty tree a known object Johannes Schindelin
2006-12-10 18:37 ` Linus Torvalds
2006-12-10 21:21 ` Junio C Hamano
2006-12-10 21:31 ` Linus Torvalds
2006-12-10 22:33 ` Junio C Hamano
2006-12-10 22:54 ` Linus Torvalds
2006-12-10 22:28 ` Junio C Hamano
2006-12-10 23:16 ` Johannes Schindelin
2006-12-09 23:56 ` [PATCH 3/3] add test case for recursive merge Johannes Schindelin
2006-12-10 0:18 ` Johannes Schindelin
2006-12-10 3:10 ` Junio C Hamano
2006-12-10 22:51 ` Johannes Schindelin
2006-12-12 22:49 ` [PATCH] t6024: fix timing problem Johannes Schindelin
2006-12-12 23:23 ` Junio C Hamano
2006-12-12 23:59 ` Johannes Schindelin
2006-12-13 3:05 ` Johannes Schindelin [this message]
2006-12-13 6:33 ` [PATCH] merge-recursive: add/add really is modify/modify with an empty base Junio C Hamano
2006-12-13 11:46 ` StGit repo & gitweb, was " Johannes Schindelin
2006-12-13 11:56 ` Jakub Narebski
2006-12-13 22:09 ` Catalin Marinas
2006-12-13 23:06 ` Robin Rosenberg
2006-12-13 23:50 ` Johannes Schindelin
2006-12-13 23:57 ` Jakub Narebski
2006-12-19 18:50 ` Petr Baudis
2006-12-19 19:39 ` Jakub Narebski
2006-12-13 22:01 ` Catalin Marinas
2006-12-13 22:26 ` Junio C Hamano
2006-12-13 23:48 ` Johannes Schindelin
2006-12-14 11:31 ` Catalin Marinas
2006-12-14 11:41 ` Shawn Pearce
2006-12-14 12:00 ` Shawn Pearce
2006-12-14 13:44 ` Johannes Schindelin
2006-12-14 14:15 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.63.0612130402300.2807@wbgn013.biozentrum.uni-wuerzburg.de \
--to=johannes.schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).