Re: [RFC] git-mergetool: show original branch names when possible

[Jeff King <peff@peff.net>]

On Mon, Aug 20, 2007 at 01:28:31AM -0700, Junio C Hamano wrote:

> I do not think of anything that would barf offhand (we already
> do that in FETCH_HEAD), but this would definitely be carefully
> audited.

I didn't say it up front, but I think this is definitely post-1.5.3
material. :)

> > 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.
> 
> Much less nice indeed.

I think this is a failing of git-merge, though, for not including that
nice human-readable information. We can fix it with something like this:

-- >8 --

diff --git a/git-merge.sh b/git-merge.sh
index e899801..742e15d 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -477,7 +477,14 @@ then
 else
 	for remote
 	do
-		echo $remote $(eval echo \$GITHEAD_$remote)
+		friendly_name=$(eval echo \$GITHEAD_$remote)
+		if echo $friendly_name | egrep -q '[0-9a-f]{40}'; then
+			friendly_name=$(
+			  sed -ne "s/$friendly_name	//p" \
+			  <"$GIT_DIR/FETCH_HEAD" 2>/dev/null
+			)
+		fi
+		echo $remote "$friendly_name"
 	done >"$GIT_DIR/MERGE_HEAD"
 	printf '%s\n' "$merge_msg" >"$GIT_DIR/MERGE_MSG"
 fi

-- 8< --

But probably it should wait for a better communications channel for
cross-command state.

> It would be very nice, and I would encourage any wannabe
> Porcelain writers to go wild on this.  One worry I have is if we
> would need to support nested states.  "I was in the middle of
> 'foo' and then had to go sideways to do 'bar' which I am now in
> the middle of" kind of thing.

It's just a stack, so I think you could implement it as a linked
list, with STATE being the head of the list, and each STATE file you
write pointing to the previous one (which you rename when pushing).

I might try to work on this, but definitely not tonight.

-Peff