{"thread":{"id":"5747","subject":"[PATCH] Use \"hash1..hash2\" instead of \"from hash1 to hash2\"","startedAt":"2006-09-28T22:11:12Z","lastAt":"2006-09-29T19:53:34Z","messageCount":3,"participants":["Santi Béjar","Junio C Hamano","Carl Worth"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"27938","messageId":"877iznbq0v.fsf@gmail.com","threadId":"5747","inReplyTo":null,"subject":"[PATCH] Use \"hash1..hash2\" instead of \"from hash1 to hash2\"","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2006-09-28T22:11:12Z","receivedAt":"2006-09-28T22:11:12Z","isPatch":true,"sender":{"key":"santi@agolina.net","avatar":null},"body":"\nSigned-off-by: Santi Béjar <sbejar@gmail.com>\n---\n git-fetch.sh   |    2 +-\n git-merge.sh   |    2 +-\n git-resolve.sh |    2 +-\n 3 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/git-fetch.sh b/git-fetch.sh\nindex 50ad101..1bc6108 100755\n--- a/git-fetch.sh\n+++ b/git-fetch.sh\n@@ -182,7 +182,7 @@ fast_forward_local () {\n \t\t;;\n \t    *,$local)\n \t\techo >&2 \"* $1: fast forward to $3\"\n-\t\techo >&2 \"  from $local to $2\"\n+\t\techo >&2 \"  $local..$2\"\n \t\tgit-update-ref -m \"$rloga: fast-forward\" \"$1\" \"$2\" \"$local\"\n \t\t;;\n \t    *)\ndiff --git a/git-merge.sh b/git-merge.sh\nindex 5b34b4d..fd587c5 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -197,7 +197,7 @@ f,*)\n \t;;\n ?,1,\"$head\",*)\n \t# Again the most common case of merging one remote.\n-\techo \"Updating from $head to $1\"\n+\techo \"Updating $head..$1\"\n \tgit-update-index --refresh 2>/dev/null\n \tnew_head=$(git-rev-parse --verify \"$1^0\") &&\n \tgit-read-tree -u -v -m $head \"$new_head\" &&\ndiff --git a/git-resolve.sh b/git-resolve.sh\nindex 729ec65..6e4fb02 100755\n--- a/git-resolve.sh\n+++ b/git-resolve.sh\n@@ -46,7 +46,7 @@ case \"$common\" in\n \texit 0\n \t;;\n \"$head\")\n-\techo \"Updating from $head to $merge\"\n+\techo \"Updating $head..$merge\"\n \tgit-read-tree -u -m $head $merge || exit 1\n \tgit-update-ref -m \"resolve $merge_name: Fast forward\" \\\n \t\tHEAD \"$merge\" \"$head\"\n-- \n1.4.2.1.g5a0f\n"},{"id":"27968","messageId":"7v7iznquc4.fsf@assigned-by-dhcp.cox.net","threadId":"5747","inReplyTo":"877iznbq0v.fsf@gmail.com","subject":"Re: [PATCH] Use \"hash1..hash2\" instead of \"from hash1 to hash2\"","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-29T02:28:59Z","receivedAt":"2006-09-29T02:28:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This kind of \"appearance only\" change needs better\njustification.  Not that I am saying \"from .. to\" is better for\nsuch and such reasons, but that's how it's been, so if you are\nproposing to change it, you need to defend why it would help\nusers (otherwise I would get hate mails that say \"why did you\nmerge it -- it broke my work habit in such and such way\").\n\nYou may be doing this for brevity.  In that case, it could\nalso be worth shortening them to n unique digits; do we have a\ncommand to get \"here is the SHA-1; give me its unique\nabbreviation at least n letters long but make it longer as\nneeded to keep it unique\"?\n\nYou may be doing this to help Cut & Paste.  Using A..B without\nspaces in between makes it easy to grab both at the same time as\na range to give them to \"git log\".  At the same time it makes it\nharder to pick only A or B, so this is two-edged.\n"},{"id":"28010","messageId":"878xk2mou9.wl%cworth@cworth.org","threadId":"5747","inReplyTo":"7v7iznquc4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Use \"hash1..hash2\" instead of \"from hash1 to hash2\"","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-09-29T19:53:34Z","receivedAt":"2006-09-29T19:53:34Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 28 Sep 2006 19:28:59 -0700, Junio C Hamano wrote:\n>\n> You may be doing this to help Cut & Paste.  Using A..B without\n> spaces in between makes it easy to grab both at the same time as\n> a range to give them to \"git log\".  At the same time it makes it\n> harder to pick only A or B, so this is two-edged.\n>\n\nI had requested this change once to help cut and paste.\n\nThe current behavior I get for selecting hash1..hash2 with (for\nexample) gnome-terminal is somewhat unfortunate, (double-clicking on\nany character selects the pair plus the separator). Obviously, '.'\nmust be considered a word character, not a separator. I wonder if such\nselection is easily capable of being told to consider \"..\" a word\nseparator? If so, it seems the output would be quite convenient\nwhether one or two of the hashes were desired for selection.\n\n-Carl\n"}]}