[PATCH] fetch: Add output for the not fast forward case

[PATCH] fetch: Add output for the not fast forward case

[Santi Béjar]

Signed-off-by: Santi Béjar <sbejar@gmail.com>
---

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

diff --git a/git-fetch.sh b/git-fetch.sh
index 1bc6108..15d6800 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -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

Re: [PATCH] fetch: Add output for the not fast forward case

[Junio C Hamano]

Santi Béjar <sbejar@gmail.com> writes:

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

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.