threads / patch / 3299

patchallow double click on current HEAD id after git-pull

Subject: [PATCH] allow double click on current HEAD id after git-pull

## tl;dr

6 messages between Feb 11, 2006 and Mar 10, 2006. Diffs are folded; open one to read it.

replies: 5people: 5as markdown or json

Olaf Hering· Feb 11, 2006, 11:26 UTC · lore

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>

Show changes to diff +2 −2

Index: git-1.1.3/git-merge.sh
===================================================================
--- git-1.1.3.orig/git-merge.sh
+++ 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
===================================================================
--- git-1.1.3.orig/git-resolve.sh
+++ 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

Petr Baudis· Mar 9, 2006, 21:02 UTC · re: Olaf Hering · lore

Re: [PATCH] allow double click on current HEAD id after git-pull

Dear diary, on Sat, Feb 11, 2006 at 12:26:30PM CET, I got a letter where Olaf Hering <olh@suse.de> said that...

Show 8 quoted lines

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

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

Junio C Hamano· Mar 9, 2006, 23:17 UTC · re: Petr Baudis · lore

Re: [PATCH] allow double click on current HEAD id after git-pull

Petr Baudis <pasky@suse.cz> writes:

Show 13 quoted lines

> Dear diary, on Sat, Feb 11, 2006 at 12:26:30PM CET, I got a letter
> where Olaf Hering <olh@suse.de> said that...
>> 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.
>                                                                                                     ^
>
> Junio, is there any particular reason why this hasn't been applied?

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.

Carl Worth· Mar 10, 2006, 00:25 UTC · re: Junio C Hamano · lore

Re: [PATCH] allow double click on current HEAD id after git-pull

On Thu, 09 Mar 2006 15:17:29 -0800, Junio C Hamano wrote:

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

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

Mark Wooding· Mar 10, 2006, 00:49 UTC · re: Junio C Hamano · lore

Re: [PATCH] allow double click on current HEAD id after git-pull

Junio C Hamano <junkio@cox.net> wrote:

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

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]

Petr Baudis· Mar 10, 2006, 01:24 UTC · re: Junio C Hamano · lore

Re: [PATCH] allow double click on current HEAD id after git-pull

Dear diary, on Fri, Mar 10, 2006 at 12:17:29AM CET, I got a letter where Junio C Hamano <junkio@cox.net> said that...

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

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

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

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