fetch: Add output for the not fast forward case

---

This patch follows the notation of the other mail, but for the not-fast-forward case I think it makes more sense to use the '...' notation. If you don't like it, just use:

+ echo >&2 " from $local to $2"

 git-fetch.sh |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

index 1bc6108..15d6800 100755
@@ -190,6 +190,7 @@ fast_forward_local () {
 		;;
 	    esac || {
 		echo >&2 "* $1: does not fast forward to $3;"
+		echo >&2 "  $local...$2"
 		case ",$force,$single_force," in
 		*,t,*)
 			echo >&2 "  forcing update."

1.4.2.1.g5a0f

Again, justification for three-dots not two as others is needed in the commit log part, not the commentary part.

I tend to agree with you that A...B is nice in this case, _if_ we use A..B for others. Using A..B for others (I am guessing that you are doing this for Cut & Paste reasons to grab the whole range as one word) means that we assume users are a lot more likely to be interested in grabbing A..B as a range than grabbing only A or B as a point.

I will not discuss if that assumption is correct here, but if we assume it is, using A...B makes a lot of sense for this case. After grabbing A..B in other cases, the user can give that to "git log" to see what the changes between old and new are. In this non-fast-forward case, if we used three-dots A...B to talk about the two heads, the user can give it to "git log" to see how the two non-fast-forward heads have diverged.

So the choice of .. and ... are internally consistent and very sensible.

The question is if people more often want to grab both as a range than they want to grab either end point alone. I am inclined to think your assumption is correct, but am not absolutely sure.