git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* Ugly "git pull .." merge messages
@ 2005-09-02  7:46 Linus Torvalds
  2005-09-02  9:39 ` [PATCH] Fix automerge message Junio C Hamano
  0 siblings, 1 reply; 2+ messages in thread
From: Linus Torvalds @ 2005-09-02  7:46 UTC (permalink / raw)
  To: Junio C Hamano; +Cc: Git Mailing List


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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [PATCH] Fix automerge message.
  2005-09-02  7:46 Ugly "git pull .." merge messages Linus Torvalds
@ 2005-09-02  9:39 ` Junio C Hamano
  0 siblings, 0 replies; 2+ messages in thread
From: Junio C Hamano @ 2005-09-02  9:39 UTC (permalink / raw)
  To: Linus Torvalds; +Cc: Git Mailing List

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"

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2005-09-02  9:39 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-09-02  7:46 Ugly "git pull .." merge messages Linus Torvalds
2005-09-02  9:39 ` [PATCH] Fix automerge message Junio C Hamano

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).