git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>, Theodore Ts'o <tytso@mit.edu>
Subject: [RFC] git-mergetool: show original branch names when possible
Date: Mon, 20 Aug 2007 03:53:18 -0400	[thread overview]
Message-ID: <20070820075318.GA12478@coredump.intra.peff.net> (raw)

The actual branch names are used when naming temporary files
and when presenting the files to the user, instead of
calling them "local" and "remote".

The "local" branch name is gathered by dereferencing HEAD.

The "remote" branch name is placed in MERGE_HEAD by
git-merge.

Signed-off-by: Jeff King <peff@peff.net>
---
I have several uncertainties in the implementation:

1. Is it OK to place the extra branch name information in MERGE_HEAD
after the SHA1?

2. It looks like doing an anonymous 'git-pull' leaves GITHEAD_* as the
commit sha1, which means you will end up with that sha1 rather than
'REMOTE', which is less nice than the current behavior. However, I think
that is fixable at the 'git-merge' level to produce a nicer name for the
remote.

3. This is meant to work similar to the GITHEAD_* feature, but needs to
work without using the environment. Many other scripts use GITHEAD_*,
but not MERGE_HEAD, so perhaps MERGE_HEAD is not the best place for
this.

It would be _really_ convenient in this case if we had a "git is in the
middle of something" file, which has been discussed before. Clearly
there are some operations that persist across multiple command
invocations, and it would be nice rather than every command knowing
about every other command's implementation patterns ("Oh, you have a
.dotest file? You must be in the middle of...") to have a single place
with something like:

  $ cat .git/STATE
  operation: merge
  remote: git://git.kernel.org/pub/scm/git/git.git
  branch: master
  branch: octopus

  $ cat .git/STATE
  operation: rebase
  upstream: origin/master
  onto: HEAD~20

where you could have arbitrary keys through which to communicate. Most
command would just look at 'operation' (e.g., if operation == merge,
don't start a new merge), but some could use the information (which
would otherwise be lost) to work more usefully (e.g., git-mergetool
understands remote and branch keys created by git-merge).

Thoughts?

 git-merge.sh     |    2 +-
 git-mergetool.sh |   24 ++++++++++++++++--------
 2 files changed, 17 insertions(+), 9 deletions(-)

diff --git a/git-merge.sh b/git-merge.sh
index 5ccf282..e899801 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -477,7 +477,7 @@ then
 else
 	for remote
 	do
-		echo $remote
+		echo $remote $(eval echo \$GITHEAD_$remote)
 	done >"$GIT_DIR/MERGE_HEAD"
 	printf '%s\n' "$merge_msg" >"$GIT_DIR/MERGE_MSG"
 fi
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 47a8055..8bc0a66 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -151,8 +151,16 @@ merge_file () {
     fi
 
     BACKUP="$path.BACKUP.$$"
-    LOCAL="$path.LOCAL.$$"
-    REMOTE="$path.REMOTE.$$"
+    local_branch=$(
+      git-symbolic-ref HEAD 2>/dev/null \
+        | sed -e 's#^refs/[^/]*/##' \
+        | sed -e 's/[^A-Za-z0-9]/-/g')
+    LOCAL="$path.${local_branch:-HEAD}.$$"
+    remote_branch=$(
+      sed -ne '1s/^[0-9a-f]* //p' \
+        <"$GIT_DIR/MERGE_HEAD" \
+        | sed -e 's/[^A-Za-z0-9]/-/g')
+    REMOTE="$path.${remote_branch:-REMOTE}.$$"
     BASE="$path.BASE.$$"
 
     mv -- "$path" "$BACKUP"
@@ -168,23 +176,23 @@ merge_file () {
 
     if test -z "$local_mode" -o -z "$remote_mode"; then
 	echo "Deleted merge conflict for '$path':"
-	describe_file "$local_mode" "local" "$LOCAL"
-	describe_file "$remote_mode" "remote" "$REMOTE"
+	describe_file "$local_mode" "${local_branch:-HEAD}" "$LOCAL"
+	describe_file "$remote_mode" "${remote_branch:-remote}" "$REMOTE"
 	resolve_deleted_merge
 	return
     fi
 
     if is_symlink "$local_mode" || is_symlink "$remote_mode"; then
 	echo "Symbolic link merge conflict for '$path':"
-	describe_file "$local_mode" "local" "$LOCAL"
-	describe_file "$remote_mode" "remote" "$REMOTE"
+	describe_file "$local_mode" "${local_branch:-HEAD}" "$LOCAL"
+	describe_file "$remote_mode" "${remote_branch:-remote}" "$REMOTE"
 	resolve_symlink_merge
 	return
     fi
 
     echo "Normal merge conflict for '$path':"
-    describe_file "$local_mode" "local" "$LOCAL"
-    describe_file "$remote_mode" "remote" "$REMOTE"
+    describe_file "$local_mode" "${local_branch:-HEAD}" "$LOCAL"
+    describe_file "$remote_mode" "${remote_branch:-remote}" "$REMOTE"
     printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
     read ans
 
-- 
1.5.3.rc5.844.g67b3-dirty

             reply	other threads:[~2007-08-20  7:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-20  7:53 Jeff King [this message]
2007-08-20  8:28 ` [RFC] git-mergetool: show original branch names when possible Junio C Hamano
2007-08-20  8:52   ` Jeff King
2007-08-20 18:17     ` Jan Hudec
2007-08-21  6:10       ` Jeff King
2007-08-21 14:59         ` Jan Hudec
2007-08-21 20:55           ` Jeff King
2007-08-21 21:17             ` Junio C Hamano

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070820075318.GA12478@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=tytso@mit.edu \
    /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.
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 NNTP newsgroup(s).