{"thread":{"id":"5748","subject":"[PATCH] fetch: Add output for the not fast forward case","startedAt":"2006-09-28T22:15:34Z","lastAt":"2006-09-29T02:29:00Z","messageCount":2,"participants":["Santi Béjar","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"27940","messageId":"873babbptl.fsf@gmail.com","threadId":"5748","inReplyTo":null,"subject":"[PATCH] fetch: Add output for the not fast forward case","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2006-09-28T22:15:34Z","receivedAt":"2006-09-28T22:15:34Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"\nSigned-off-by: Santi Béjar <sbejar@gmail.com>\n---\n\nThis patch follows the notation of the other mail, but for the\nnot-fast-forward case I think it makes more sense to use the '...'\nnotation. If you don't like it, just use:\n\n+\t\techo >&2 \"  from $local to $2\"\n\n git-fetch.sh |    1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/git-fetch.sh b/git-fetch.sh\nindex 1bc6108..15d6800 100755\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -190,6 +190,7 @@ fast_forward_local () {\n \t\t;;\n \t    esac || {\n \t\techo >&2 \"* $1: does not fast forward to $3;\"\n+\t\techo >&2 \"  $local...$2\"\n \t\tcase \",$force,$single_force,\" in\n \t\t*,t,*)\n \t\t\techo >&2 \"  forcing update.\"\n-- \n1.4.2.1.g5a0f\n"},{"id":"27969","messageId":"7v1wpvquc3.fsf@assigned-by-dhcp.cox.net","threadId":"5748","inReplyTo":"873babbptl.fsf@gmail.com","subject":"Re: [PATCH] fetch: Add output for the not fast forward case","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-29T02:29:00Z","receivedAt":"2006-09-29T02:29:00Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Santi Béjar <sbejar@gmail.com> writes:\n\n> This patch follows the notation of the other mail, but for the\n> not-fast-forward case I think it makes more sense to use the '...'\n> notation.\n\nAgain, justification for three-dots not two as others is needed\nin the commit log part, not the commentary part.\n\nI tend to agree with you that A...B is nice in this case, _if_\nwe use A..B for others.  Using A..B for others (I am guessing\nthat you are doing this for Cut & Paste reasons to grab the\nwhole range as one word) means that we assume users are a lot\nmore likely to be interested in grabbing A..B as a range than\ngrabbing only A or B as a point.\n\nI will not discuss if that assumption is correct here, but if we\nassume it is, using A...B makes a lot of sense for this case.\nAfter grabbing A..B in other cases, the user can give that to\n\"git log\" to see what the changes between old and new are.  In\nthis non-fast-forward case, if we used three-dots A...B to talk\nabout the two heads, the user can give it to \"git log\" to see\nhow the two non-fast-forward heads have diverged.\n\nSo the choice of .. and ... are internally consistent and very\nsensible.\n\nThe question is if people more often want to grab both as a\nrange than they want to grab either end point alone.  I am\ninclined to think your assumption is correct, but am not\nabsolutely sure.\n"}]}