git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC/PATCH] mergetool: clarify local/remote terminology

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 29, 2008, 05:47 UTC
Message-ID
<7v3arcfh54.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<20080228084328.GA18350@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I like it; I think it made it a lot more obvious which side was which
> during the rebase. I checked with cherry-pick, as well; it more or less
> makes sense, except that the cherry-picked commit is called "upstream."

While I like the fact that somebody is trying to tackle the consistency issue, I do not like the approach itself. Fudging the issue at the merge-tool UI level may make things appear more consistent when viewing the merge from within merge-tool, but it makes the views merge-tool gives and vi/less gives inconsistent.

It would be a lot more sensible to make sure that we always show the side that the end-user modified first and then the side the other party changed.

A regular merge, cherry-pick and revert all start from user's side and play the change from the other side, and conflicted hunks are shown in the right order. It is only "rebase" (with or without -m) that gets it wrong. Even though it internally operates as if our own changes are coming from the other side, we should show our change first and then theirs to make it consistent and easier to read.

So how about doing it like this, instead? I am not proud of the use of an environment variable to pass this control around, but the idea should be obvious.

Note that some tests are written to expect the current hunk order and will start failing, so if we were to go this route, we would need to adjust them as well.

--
 git-rebase.sh |    3 +++
 ll-merge.c    |    6 ++++++
 2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index bdcea0e..422879f 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -48,6 +48,9 @@ prec=4
 verbose=
 git_am_opt=
 
+GITHEAD_SWAP_CONFLICT=in-rebase
+export GITHEAD_SWAP_CONFLICT
+
 continue_merge () {
 	test -n "$prev_head" || die "prev_head must be defined"
 	test -d "$dotest" || die "$dotest directory does not exist"
diff --git a/ll-merge.c b/ll-merge.c
index 5ae7433..1d0040f 100644
--- a/ll-merge.c
+++ b/ll-merge.c
@@ -76,6 +76,12 @@ static int ll_xdl_merge(const struct ll_merge_driver *drv_unused,
 				       virtual_ancestor);
 	}
 
+	if (getenv("GITHEAD_SWAP_CONFLICT")) {
+		mmfile_t *s;
+		const char *n;
+		s = src1; src1 = src2; src2 = s;
+		n = name1; name1 = name2; name2 = n;
+	}
 	memset(&xpp, 0, sizeof(xpp));
 	return xdl_merge(orig,
 			 src1, name1,
Previous: Jeff KingNext: Jeff King
Message 9 of 10 in “mergetool: clarify local/remote terminology”
  1. mergetool: clarify local/remote terminologyJay Soffian, Feb 21, 2008
  2. Jay SoffianFeb 25, 2008
  3. Jeff KingFeb 25, 2008
  4. Jay SoffianFeb 25, 2008
  5. Jeff KingFeb 25, 2008
  6. Jay SoffianFeb 25, 2008
  7. Jeff KingFeb 25, 2008
  8. Jeff KingFeb 28, 2008
  9. Junio C HamanoFeb 29, 2008
  10. Jeff KingMar 1, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.