Use "hash1..hash2" instead of "from hash1 to hash2"

---
 git-fetch.sh   |    2 +-
 git-merge.sh   |    2 +-
 git-resolve.sh |    2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

index 50ad101..1bc6108 100755
@@ -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"
 		;;
 	    *)

index 5b34b4d..fd587c5 100755
@@ -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" &&

index 729ec65..6e4fb02 100755
@@ -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.

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