[PATCH] Use "hash1..hash2" instead of "from hash1 to hash2"

Signed-off-by: Santi Béjar <redacted>
---
 git-fetch.sh   |    2 +-
 git-merge.sh   |    2 +-
 git-resolve.sh |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/git-fetch.sh b/git-fetch.sh
index 50ad101..1bc6108 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh

@@ -182,7 +182,7 @@ fast_forward_local () {
 		;;
 	    *,$local)
 		echo >&2 "* $1: fast forward to $3"
-		echo >&2 "  from $local to $2"
+		echo >&2 "  $local..$2"
 		git-update-ref -m "$rloga: fast-forward" "$1" "$2" "$local"
 		;;
 	    *)

diff --git a/git-merge.sh b/git-merge.sh
index 5b34b4d..fd587c5 100755
--- a/git-merge.sh
+++ b/git-merge.sh

@@ -197,7 +197,7 @@ f,*)
 	;;
 ?,1,"$head",*)
 	# Again the most common case of merging one remote.
-	echo "Updating from $head to $1"
+	echo "Updating $head..$1"
 	git-update-index --refresh 2>/dev/null
 	new_head=$(git-rev-parse --verify "$1^0") &&
 	git-read-tree -u -v -m $head "$new_head" &&

diff --git a/git-resolve.sh b/git-resolve.sh
index 729ec65..6e4fb02 100755
--- a/git-resolve.sh
+++ b/git-resolve.sh

@@ -46,7 +46,7 @@ case "$common" in
 	exit 0
 	;;
 "$head")
-	echo "Updating from $head to $merge"
+	echo "Updating $head..$merge"
 	git-read-tree -u -m $head $merge || exit 1
 	git-update-ref -m "resolve $merge_name: Fast forward" \
 		HEAD "$merge" "$head"

-- 
1.4.2.1.g5a0f

This kind of "appearance only" change needs better
justification.  Not that I am saying "from .. to" is better for
such and such reasons, but that's how it's been, so if you are
proposing to change it, you need to defend why it would help
users (otherwise I would get hate mails that say "why did you
merge it -- it broke my work habit in such and such way").

You may be doing this for brevity.  In that case, it could
also be worth shortening them to n unique digits; do we have a
command to get "here is the SHA-1; give me its unique
abbreviation at least n letters long but make it longer as
needed to keep it unique"?

You may be doing this to help Cut & Paste.  Using A..B without
spaces in between makes it easy to grab both at the same time as
a range to give them to "git log".  At the same time it makes it
harder to pick only A or B, so this is two-edged.

On Thu, 28 Sep 2006 19:28:59 -0700, Junio C Hamano wrote:

You may be doing this to help Cut & Paste.  Using A..B without
spaces in between makes it easy to grab both at the same time as
a range to give them to "git log".  At the same time it makes it
harder to pick only A or B, so this is two-edged.

I had requested this change once to help cut and paste.

The current behavior I get for selecting hash1..hash2 with (for
example) gnome-terminal is somewhat unfortunate, (double-clicking on
any character selects the pair plus the separator). Obviously, '.'
must be considered a word character, not a separator. I wonder if such
selection is easily capable of being told to consider ".." a word
separator? If so, it seems the output would be quite convenient
whether one or two of the hashes were desired for selection.

-Carl