# Ugly "git pull .." merge messages

2 messages from 2005-09-02 to 2005-09-02. Participants: Linus Torvalds, Junio C Hamano.
Thread: https://gitlist.dev/t/1713

## Linus Torvalds, 2005-09-02 07:46

Subject: Ugly "git pull .." merge messages
Message-ID: <Pine.LNX.4.58.0509011117130.6795@evo.osdl.org>
URL: https://gitlist.dev/e/Pine.LNX.4.58.0509011117130.6795%40evo.osdl.org

```

Junio, I think this happened when you rewrote the pull/push stuff to do
shorthands..

Lately, "git pull" generates a lot of extra crud in the single-line commit
message, which is annoying because a lot of tools will thus actually not
show enough of the line to be valid.

For example, it used to get rid of the ".git" at the end, and it didn't
bother to say "HEAD". So

    Merge HEAD from master.kernel.org:/home/rmk/linux-2.6-arm.git

used to be just

    Merge master.kernel.org:/home/rmk/linux-2.6-arm

which is actually much nicer. It tends to fit in the gitk description
window.

In this example:

    Merge refs/heads/release from master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6

I had manually removed the ".git" (since git-fetch-pack will happily add
it back), so it doesn't have the ".git" at the end of the message, but
instead it has a ref-name that is the internal git path rather than the
path that I actually specified. Now, we didn't use to be shorter, but at
least it used to be more readable, with

    Merge 'release' branch of master.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6

(Ok, it's slightly shorter, but not much - but my point is that it's
actually more readable).

Could we get the nicer messages back, please?

		Linus

```

## Junio C Hamano, 2005-09-02 09:39

Subject: [PATCH] Fix automerge message.
Message-ID: <7vr7c7izae.fsf@assigned-by-dhcp.cox.net>
URL: https://gitlist.dev/e/7vr7c7izae.fsf%40assigned-by-dhcp.cox.net
In-Reply-To: <Pine.LNX.4.58.0509011117130.6795@evo.osdl.org>

```
The rewrite done while adding the shorthand support made the remote
refname recorded in the commit message too long for human consumption,
while losing information by using the shorthand not the real URL to
name the remote repository there.  They were both bad changes done
without enough thinking.

Pointed out by Linus.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 git-fetch-script |   51 +++++++++++++++++++++++++++++++++------------------
 1 files changed, 33 insertions(+), 18 deletions(-)

06ec2b4bb4ab9096d1304ba5a2ec388078dcdf7f
diff --git a/git-fetch-script b/git-fetch-script
--- a/git-fetch-script
+++ b/git-fetch-script
@@ -55,21 +55,41 @@ append_fetch_head () {
     remote_nick_="$4"
     local_name_="$5"
 
+    # remote-nick is the URL given on the command line (or a shorthand)
+    # remote-name is the $GIT_DIR relative refs/ path we computed
+    # for this refspec.
+    case "$remote_name_" in
+    HEAD)
+	note_= ;;
+    refs/heads/*)
+	note_="$(expr "$remote_name_" : 'refs/heads/\(.*\)')"
+	note_="branch '$note_' of " ;;
+    refs/tags/*)
+	note_="$(expr "$remote_name_" : 'refs/tags/\(.*\)')"
+	note_="tag '$note_' of " ;;
+    *)
+	note_="$remote_name of " ;;
+    esac
+    remote_1_=$(expr "$remote_" : '\(.*\)\.git/*$') &&
+	remote_="$remote_1_"
+    note_="$note_$remote_"
+
     # 2.6.11-tree tag would not be happy to be fed to resolve.
     if git-cat-file commit "$head_" >/dev/null 2>&1
     then
 	headc_=$(git-rev-parse --verify "$head_^0") || exit
-	note_="$headc_	$remote_name_ from $remote_nick_"
-	echo "$note_" >>$GIT_DIR/FETCH_HEAD
-	echo >&2 "* committish: $note_"
+	echo "$headc_	$note_" >>$GIT_DIR/FETCH_HEAD
+	echo >&2 "* committish: $head_"
+	echo >&2 "  $note_"
     else
-	echo >&2 "* non-commit: $note_"
+	echo >&2 "* non-commit: $head_"
+	echo >&2 "  $note_"
     fi
     if test "$local_name_" != ""
     then
 	# We are storing the head locally.  Make sure that it is
 	# a fast forward (aka "reverse push").
-	fast_forward_local "$local_name_" "$head_" "$remote_" "$remote_name_"
+	fast_forward_local "$local_name_" "$head_" "$note_"
     fi
 }
 
@@ -80,11 +100,9 @@ fast_forward_local () {
 	# is no way to guarantee "fast-forward" anyway.
 	if test -f "$GIT_DIR/$1"
 	then
-		echo >&2 "* $1: updating with $4"
-		echo >&2 "  from $3."
+		echo >&2 "* $1: updating with $3"
 	else
-		echo >&2 "* $1: storing $4"
-		echo >&2 "  from $3."
+		echo >&2 "* $1: storing $3"
 	fi
 	echo "$2" >"$GIT_DIR/$1" ;;
 
@@ -97,31 +115,28 @@ fast_forward_local () {
 	    mb=$(git-merge-base "$local" "$2") &&
 	    case "$2,$mb" in
 	    $local,*)
-		echo >&2 "* $1: same as $4"
-		echo >&2 "  from $3"
+		echo >&2 "* $1: same as $3"
 		;;
 	    *,$local)
-		echo >&2 "* $1: fast forward to $4"
-		echo >&2 "  from $3"
+		echo >&2 "* $1: fast forward to $3"
 		;;
 	    *)
 		false
 		;;
 	    esac || {
-		echo >&2 "* $1: does not fast forward to $4"
+		echo >&2 "* $1: does not fast forward to $3;"
 		case "$force,$single_force" in
 		t,* | *,t)
-			echo >&2 "  from $3; forcing update."
+			echo >&2 "  forcing update."
 			;;
 		*)
 			mv "$GIT_DIR/$1.lock" "$GIT_DIR/$1.remote"
-			echo >&2 "  from $3; leaving it in '$1.remote'"
+			echo >&2 "  leaving it in '$1.remote'"
 			;;
 		esac
 	    }
 	else
-		echo >&2 "* $1: storing $4"
-		echo >&2 "  from $3."
+		echo >&2 "* $1: storing $3"
 	fi
 	test -f "$GIT_DIR/$1.lock" &&
 	    mv "$GIT_DIR/$1.lock" "$GIT_DIR/$1"

```