allow double click on current HEAD id after git-pull

Double click on to current HEAD commit id is not possible, the dot has to go.

olaf@pomegranate:~/kernel/git/linux-2.6> git-pull
Unpacking 194 objects
100% (194/194) done
* refs/heads/origin: fast forward to branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
Updating from 5bc159e6cb7ca8d173195919ee935885c129011e to 25bf368b3d98668c5d5f38e2201d8bca16e52680.
Fast forward
...
olaf@pomegranate:~/kernel/git/linux-2.6> git-whatchanged 5bc159e6cb7ca8d173195919ee935885c129011e..25bf368b3d98668c5d5f38e2201d8bca16e52680. olaf@pomegranate:~/kernel/git/linux-2.6> git-whatchanged 5bc159e6cb7ca8d173195919ee935885c129011e..25bf368b3d98668c5d5f38e2201d8bca16e52680 <stuff>

Index: git-1.1.3/git-merge.sh
===================================================================
@@ -127,7 +127,7 @@ case "$#,$common,$no_commit" in
 	;;
 1,"$head",*)
 	# Again the most common case of merging one remote.
-	echo "Updating from $head to $1."
+	echo "Updating from $head to $1"
 	git-update-index --refresh 2>/dev/null
 	new_head=$(git-rev-parse --verify "$1^0") &&
 	git-read-tree -u -m $head "$new_head" &&

Index: git-1.1.3/git-resolve.sh
===================================================================
@@ -41,7 +41,7 @@ case "$common" in
 	exit 0
 	;;
 "$head")
-	echo "Updating from $head to $merge."
+	echo "Updating from $head to $merge"
 	git-read-tree -u -m $head $merge || exit 1
 	git-update-ref HEAD "$merge" "$head"
 	git-diff-tree -p $head $merge | git-apply --stat

short story of a lazy sysadmin:
 alias appserv=wotan

Dear diary, on Sat, Feb 11, 2006 at 12:26:30PM CET, I got a letter where Olaf Hering <[email protected]> said that...

                                                                                                    ^

Junio, is there any particular reason why this hasn't been applied?

Thanks,

				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams

Well I kind of like ending a sentence with a full stop. Isn't this something you can do by confuguiring your cut&paste?

But I do not have a _very_ strong feeling either way. If majority of the list wants it that way I do not mind.

Dear diary, on Fri, Mar 10, 2006 at 12:17:29AM CET, I got a letter where Junio C Hamano <[email protected]> said that...

I wouldn't think cut'n'paste is usually that flexible and/or easy to configure.

Being able to easily cut'n'paste is IMHO an important usability thing, and with that long sha1s, who's going to notice a missing fullstop far at the right? ;-)

				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe.  -- Douglas Adams

If the cut-and-paste configuration is limited to just word characters vs. word-separating characters, then no. At least not and also preserve the ability to select numbers of the form 1.25 .

I don't know if an extra space like the above is good style, but it is what I have sometimes caught myself doing when ending a sentence with a URL, for example.

-Carl

Could do, but since . is a useful filename character it usually seems like a good idea to include it in the set of characters considered a `word' by the terminal double-click logic. I've not used xterm for ages, but a quick check shows that Eterm isn't smart enough to be told that . followed by a word-constituent is good and should be included in a word, whereas a trailing . is a different thing which it doesn't want to include.

So I'm in favour of killing the full-stops. Sorry. :-(

-- [mdw]