git gui: Possible to see which commands are executed?

git gui: Possible to see which commands are executed?

[Dirk Süsserott]

Is it possible to see which commands are executed by git-gui?
For an example, there's a menu item "branch -> rename".
I'm not aware that such a thing as "git branch rename"
exists on the command line. So git-gui must do it by
other means. Is there a way to see how? (Don't stick with
this example, it's a general question.)
Some "--debug" or "--log" switch which logs the
commands to a logfile or so? I know I could examine the
sources but that's not convenient ;-)

It would be really cool when git-gui could show the command
in a different window *before* it is executed. Some database
frontends have an option "show SQL statement", but I think
that would be demanded too much.

    Dirk

Re: git gui: Possible to see which commands are executed?

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 290 bytes --]

On Sun, May 18, 2008 at 02:03:35PM +0200, Dirk Süsserott <newsletter@dirk.my1.cc> wrote:
> I'm not aware that such a thing as "git branch rename"
> exists on the command line.

man git-branch, search for rename:

"With a -m or -M option, <oldbranch> will be renamed to <newbranch>."

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: git gui: Possible to see which commands are executed?

[Dirk Süsserott]

Miklos Vajna schrieb:
> On Sun, May 18, 2008 at 02:03:35PM +0200, Dirk Süsserott <newsletter@dirk.my1.cc> wrote:
>   
>> I'm not aware that such a thing as "git branch rename"
>> exists on the command line.
>>     
>
> man git-branch, search for rename:
>
> "With a -m or -M option, <oldbranch> will be renamed to <newbranch>."
>   
Thanks. Ok, I missed that "rename branch" switch :-(. But that was just 
an example.
I'm actually looking for a 'git gui --log' switch to show me your very 
answer.

Re: git gui: Possible to see which commands are executed?

[Shawn O. Pearce]

Dirk Ssserott <newsletter@dirk.my1.cc> wrote:
> Is it possible to see which commands are executed by git-gui?
...
> It would be really cool when git-gui could show the command
> in a different window *before* it is executed. Some database
> frontends have an option "show SQL statement", but I think
> that would be demanded too much.

Not presently, no.  People have asked for this in the past, but
its not as easy as it sounds.  git-gui tries to drive the plumbing
commands when possible, not the porcelain that most humans use.
Consequently the stream of commands that git-gui issues is quite
different from what a human would type on the command line, yet
the end result is equivilant.

I hacked this up earlier today on my Cygwin system, just to show you
what I mean.  With the attached patch applied I restarted git-gui
with `git gui --trace` (which this patch introduces) and then used
git-gui to commit this patch to its own repository.

Stop me when you see a command you might type yourself.  ;-)

  C:/cygwin/usr/local/git/bin/git.exe --version
  < git version 1.5.5.1.450.gee27
  C:/cygwin/usr/local/git/bin/git.exe --exec-path
  < /usr/local/git/bin
  C:/cygwin/usr/local/git/bin/git-rev-parse.exe --git-dir
  < .git
  C:/cygwin/usr/local/git/bin/git-rev-parse.exe --show-prefix
  < 
  C:/cygwin/usr/local/git/bin/git-config.exe --null --list
  C:/cygwin/usr/local/git/bin/git-rev-parse.exe --verify HEAD
  < 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7
  C:/cygwin/usr/local/git/bin/git-update-index.exe -q --unmerged --ignore-missing --refresh
  C:/cygwin/usr/local/git/bin/git-diff-index.exe --cached -z 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7
  C:/cygwin/usr/local/git/bin/git-diff-files.exe -z
  C:/cygwin/usr/local/git/bin/git-ls-files.exe --others -z --exclude-per-directory=.gitignore --exclude-from=.git/info/exclude
  C:/cygwin/usr/local/git/bin/git-rev-parse.exe --verify HEAD
  < 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7
  C:/cygwin/usr/local/git/bin/git-update-index.exe -q --unmerged --ignore-missing --refresh
  C:/cygwin/usr/local/git/bin/git-diff-index.exe --cached -z 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7
  C:/cygwin/usr/local/git/bin/git-diff-files.exe -z
  C:/cygwin/usr/local/git/bin/git-ls-files.exe --others -z --exclude-per-directory=.gitignore --exclude-from=.git/info/exclude
  C:/cygwin/usr/local/git/bin/git-update-index.exe --add --remove -z --stdin
  C:/cygwin/usr/local/git/bin/git-var.exe GIT_COMMITTER_IDENT
  < Shawn O. Pearce <spearce@spearce.org> 1211130496 -0400
  C:/cygwin/usr/local/git/bin/git-rev-parse.exe --verify HEAD
  < 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7
  C:/cygwin/bin/sh.exe -c 'if test -x "$1";then exec "$@";fi'
  C:/cygwin/bin/sh.exe .git/hooks/pre-commit 2>@1
  C:/cygwin/bin/sh.exe -c 'if test -x "$1";then exec "$@";fi'
  C:/cygwin/bin/sh.exe .git/hooks/commit-msg .git/GITGUI_EDITMSG 2>@1
  C:/cygwin/usr/local/git/bin/git-write-tree.exe
  C:/cygwin/usr/local/git/bin/git-cat-file.exe commit 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7
  C:/cygwin/usr/local/git/bin/git-commit-tree.exe 26a475c0a74f51872513993c41e8e15286df9fa5 -p 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7 <.git/GITGUI_EDITMSG
  < cc33ff6ec3582522edaae00354d9b96a797ecf09
  C:/cygwin/usr/local/git/bin/git-update-ref.exe -m 'commit: git-gui: Add a --trace command line option' HEAD cc33ff6ec3582522edaae00354d9b96a797ecf09 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7
  < 
  C:/cygwin/bin/sh.exe -c 'if test -x "$1";then exec "$@";fi'
  C:/cygwin/bin/sh.exe .git/hooks/post-commit 2>@1

Right.  So I'm not certain how useful this patch really is.  It is
fairly short as all calls to git go through one of three procedures.


--8<--
git-gui: Add a --trace command line option

---
 git-gui.sh |   47 +++++++++++++++++++++++++++++++++++++++--------
 1 files changed, 39 insertions(+), 8 deletions(-)

diff --git a/git-gui.sh b/git-gui.sh
index 9df4971..6a8831a 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -122,6 +122,14 @@ set _reponame {}
 set _iscygwin {}
 set _search_path {}
 
+set _trace [lsearch -exact $argv --trace]
+if {$_trace >= 0} {
+	set argv [lreplace $argv $_trace $_trace]
+	set _trace 1
+} else {
+	set _trace 0
+}
+
 proc appname {} {
 	global _appname
 	return $_appname
@@ -245,6 +253,21 @@ proc get_config {name} {
 ##
 ## handy utils
 
+proc _trace_exec {cmd} {
+	if {!$::_trace} return
+	set d {}
+	foreach v $cmd {
+		if {$d ne {}} {
+			append d { }
+		}
+		if {[regexp {[ \t\r\n'"$?*]} $v]} {
+			set v [sq $v]
+		}
+		append d $v
+	}
+	puts stderr $d
+}
+
 proc _git_cmd {name} {
 	global _git_cmd_path
 
@@ -339,7 +362,7 @@ proc _lappend_nice {cmd_var} {
 }
 
 proc git {args} {
-	set opt [list exec]
+	set opt [list]
 
 	while {1} {
 		switch -- [lindex $args 0] {
@@ -359,12 +382,18 @@ proc git {args} {
 	set cmdp [_git_cmd [lindex $args 0]]
 	set args [lrange $args 1 end]
 
-	return [eval $opt $cmdp $args]
+	_trace_exec [concat $opt $cmdp $args]
+	set result [eval exec $opt $cmdp $args]
+	if {$::_trace} {
+		puts stderr "< $result"
+	}
+	return $result
 }
 
 proc _open_stdout_stderr {cmd} {
+	_trace_exec $cmd
 	if {[catch {
-			set fd [open $cmd r]
+			set fd [open [concat [list | ] $cmd] r]
 		} err]} {
 		if {   [lindex $cmd end] eq {2>@1}
 		    && $err eq {can not find channel named "1"}
@@ -375,6 +404,7 @@ proc _open_stdout_stderr {cmd} {
 			# to try to start it a second time.
 			#
 			set fd [open [concat \
+				[list | ] \
 				[lrange $cmd 0 end-1] \
 				[list |& cat] \
 				] r]
@@ -387,7 +417,7 @@ proc _open_stdout_stderr {cmd} {
 }
 
 proc git_read {args} {
-	set opt [list |]
+	set opt [list]
 
 	while {1} {
 		switch -- [lindex $args 0] {
@@ -415,7 +445,7 @@ proc git_read {args} {
 }
 
 proc git_write {args} {
-	set opt [list |]
+	set opt [list]
 
 	while {1} {
 		switch -- [lindex $args 0] {
@@ -435,7 +465,8 @@ proc git_write {args} {
 	set cmdp [_git_cmd [lindex $args 0]]
 	set args [lrange $args 1 end]
 
-	return [open [concat $opt $cmdp $args] w]
+	_trace_exec [concat $opt $cmdp $args]
+	return [open [concat [list | ] $opt $cmdp $args] w]
 }
 
 proc githook_read {hook_name args} {
@@ -455,12 +486,12 @@ proc githook_read {hook_name args} {
 		}
 
 		set scr {if test -x "$1";then exec "$@";fi}
-		set sh_c [list | $interp -c $scr $interp $pchook]
+		set sh_c [list $interp -c $scr $interp $pchook]
 		return [_open_stdout_stderr [concat $sh_c $args]]
 	}
 
 	if {[file executable $pchook]} {
-		return [_open_stdout_stderr [concat [list | $pchook] $args]]
+		return [_open_stdout_stderr [concat [list $pchook] $args]]
 	}
 
 	return {}
-- 
1.5.5.1.450.gee27


-- 
Shawn.

Re: git gui: Possible to see which commands are executed?

[Dirk Süsserott]

Shawn O. Pearce schrieb:
> Dirk Ssserott <newsletter@dirk.my1.cc> wrote:
>   
>> Is it possible to see which commands are executed by git-gui?
>>     
> ...
>   
>> It would be really cool when git-gui could show the command
>> in a different window *before* it is executed. Some database
>> frontends have an option "show SQL statement", but I think
>> that would be demanded too much.
>>     
>
> Not presently, no.  People have asked for this in the past, but
> its not as easy as it sounds.  git-gui tries to drive the plumbing
> commands when possible, not the porcelain that most humans use.
> Consequently the stream of commands that git-gui issues is quite
> different from what a human would type on the command line, yet
> the end result is equivilant.
>
> I hacked this up earlier today on my Cygwin system, just to show you
> what I mean.  With the attached patch applied I restarted git-gui
> with `git gui --trace` (which this patch introduces) and then used
> git-gui to commit this patch to its own repository.
>
> Stop me when you see a command you might type yourself.  ;-)
>   

Hi Shawn,

thanks for your patch. Actually I had problems applying it and
finally gave up. I'm using the msysGit package which seems quite
similar to the cygwin package but not in all cases, apparently.

However, you were right. The trace doesn't show the commands I
would use on a regular basis (I couldn't stop you :-)).
On the other hand it possibly helps to /understand/ (or at least
/see/) what's going on under the hood.

For that reason I'd greatly appreciate seeing your patch in some
future version of Git. It doesn't do any harm, does it? People
that don't like it can simply omit the '--trace' switch.

Junio? The list?

    Dirk

>   C:/cygwin/usr/local/git/bin/git.exe --version
>   < git version 1.5.5.1.450.gee27
>   C:/cygwin/usr/local/git/bin/git.exe --exec-path
>   < /usr/local/git/bin
>   C:/cygwin/usr/local/git/bin/git-rev-parse.exe --git-dir
>   < .git
>   C:/cygwin/usr/local/git/bin/git-rev-parse.exe --show-prefix
>   < 
>   C:/cygwin/usr/local/git/bin/git-config.exe --null --list
>   C:/cygwin/usr/local/git/bin/git-rev-parse.exe --verify HEAD
>   < 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7
>   C:/cygwin/usr/local/git/bin/git-update-index.exe -q --unmerged --ignore-missing --refresh
>   C:/cygwin/usr/local/git/bin/git-diff-index.exe --cached -z 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7
>   C:/cygwin/usr/local/git/bin/git-diff-files.exe -z
>   C:/cygwin/usr/local/git/bin/git-ls-files.exe --others -z --exclude-per-directory=.gitignore --exclude-from=.git/info/exclude
>   C:/cygwin/usr/local/git/bin/git-rev-parse.exe --verify HEAD
>   < 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7
>   C:/cygwin/usr/local/git/bin/git-update-index.exe -q --unmerged --ignore-missing --refresh
>   C:/cygwin/usr/local/git/bin/git-diff-index.exe --cached -z 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7
>   C:/cygwin/usr/local/git/bin/git-diff-files.exe -z
>   C:/cygwin/usr/local/git/bin/git-ls-files.exe --others -z --exclude-per-directory=.gitignore --exclude-from=.git/info/exclude
>   C:/cygwin/usr/local/git/bin/git-update-index.exe --add --remove -z --stdin
>   C:/cygwin/usr/local/git/bin/git-var.exe GIT_COMMITTER_IDENT
>   < Shawn O. Pearce <spearce@spearce.org> 1211130496 -0400
>   C:/cygwin/usr/local/git/bin/git-rev-parse.exe --verify HEAD
>   < 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7
>   C:/cygwin/bin/sh.exe -c 'if test -x "$1";then exec "$@";fi'
>   C:/cygwin/bin/sh.exe .git/hooks/pre-commit 2>@1
>   C:/cygwin/bin/sh.exe -c 'if test -x "$1";then exec "$@";fi'
>   C:/cygwin/bin/sh.exe .git/hooks/commit-msg .git/GITGUI_EDITMSG 2>@1
>   C:/cygwin/usr/local/git/bin/git-write-tree.exe
>   C:/cygwin/usr/local/git/bin/git-cat-file.exe commit 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7
>   C:/cygwin/usr/local/git/bin/git-commit-tree.exe 26a475c0a74f51872513993c41e8e15286df9fa5 -p 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7 <.git/GITGUI_EDITMSG
>   < cc33ff6ec3582522edaae00354d9b96a797ecf09
>   C:/cygwin/usr/local/git/bin/git-update-ref.exe -m 'commit: git-gui: Add a --trace command line option' HEAD cc33ff6ec3582522edaae00354d9b96a797ecf09 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7
>   < 
>   C:/cygwin/bin/sh.exe -c 'if test -x "$1";then exec "$@";fi'
>   C:/cygwin/bin/sh.exe .git/hooks/post-commit 2>@1
>
> Right.  So I'm not certain how useful this patch really is.  It is
> fairly short as all calls to git go through one of three procedures.
>
>
> --8<--
> git-gui: Add a --trace command line option
>
> ---
>  git-gui.sh |   47 +++++++++++++++++++++++++++++++++++++++--------
>  1 files changed, 39 insertions(+), 8 deletions(-)
>
> diff --git a/git-gui.sh b/git-gui.sh
> index 9df4971..6a8831a 100755
> --- a/git-gui.sh
> +++ b/git-gui.sh
> @@ -122,6 +122,14 @@ set _reponame {}
>  set _iscygwin {}
>  set _search_path {}
>  
> +set _trace [lsearch -exact $argv --trace]
> +if {$_trace >= 0} {
> +	set argv [lreplace $argv $_trace $_trace]
> +	set _trace 1
> +} else {
> +	set _trace 0
> +}
> +
>  proc appname {} {
>  	global _appname
>  	return $_appname
> @@ -245,6 +253,21 @@ proc get_config {name} {
>  ##
>  ## handy utils
>  
> +proc _trace_exec {cmd} {
> +	if {!$::_trace} return
> +	set d {}
> +	foreach v $cmd {
> +		if {$d ne {}} {
> +			append d { }
> +		}
> +		if {[regexp {[ \t\r\n'"$?*]} $v]} {
> +			set v [sq $v]
> +		}
> +		append d $v
> +	}
> +	puts stderr $d
> +}
> +
>  proc _git_cmd {name} {
>  	global _git_cmd_path
>  
> @@ -339,7 +362,7 @@ proc _lappend_nice {cmd_var} {
>  }
>  
>  proc git {args} {
> -	set opt [list exec]
> +	set opt [list]
>  
>  	while {1} {
>  		switch -- [lindex $args 0] {
> @@ -359,12 +382,18 @@ proc git {args} {
>  	set cmdp [_git_cmd [lindex $args 0]]
>  	set args [lrange $args 1 end]
>  
> -	return [eval $opt $cmdp $args]
> +	_trace_exec [concat $opt $cmdp $args]
> +	set result [eval exec $opt $cmdp $args]
> +	if {$::_trace} {
> +		puts stderr "< $result"
> +	}
> +	return $result
>  }
>  
>  proc _open_stdout_stderr {cmd} {
> +	_trace_exec $cmd
>  	if {[catch {
> -			set fd [open $cmd r]
> +			set fd [open [concat [list | ] $cmd] r]
>  		} err]} {
>  		if {   [lindex $cmd end] eq {2>@1}
>  		    && $err eq {can not find channel named "1"}
> @@ -375,6 +404,7 @@ proc _open_stdout_stderr {cmd} {
>  			# to try to start it a second time.
>  			#
>  			set fd [open [concat \
> +				[list | ] \
>  				[lrange $cmd 0 end-1] \
>  				[list |& cat] \
>  				] r]
> @@ -387,7 +417,7 @@ proc _open_stdout_stderr {cmd} {
>  }
>  
>  proc git_read {args} {
> -	set opt [list |]
> +	set opt [list]
>  
>  	while {1} {
>  		switch -- [lindex $args 0] {
> @@ -415,7 +445,7 @@ proc git_read {args} {
>  }
>  
>  proc git_write {args} {
> -	set opt [list |]
> +	set opt [list]
>  
>  	while {1} {
>  		switch -- [lindex $args 0] {
> @@ -435,7 +465,8 @@ proc git_write {args} {
>  	set cmdp [_git_cmd [lindex $args 0]]
>  	set args [lrange $args 1 end]
>  
> -	return [open [concat $opt $cmdp $args] w]
> +	_trace_exec [concat $opt $cmdp $args]
> +	return [open [concat [list | ] $opt $cmdp $args] w]
>  }
>  
>  proc githook_read {hook_name args} {
> @@ -455,12 +486,12 @@ proc githook_read {hook_name args} {
>  		}
>  
>  		set scr {if test -x "$1";then exec "$@";fi}
> -		set sh_c [list | $interp -c $scr $interp $pchook]
> +		set sh_c [list $interp -c $scr $interp $pchook]
>  		return [_open_stdout_stderr [concat $sh_c $args]]
>  	}
>  
>  	if {[file executable $pchook]} {
> -		return [_open_stdout_stderr [concat [list | $pchook] $args]]
> +		return [_open_stdout_stderr [concat [list $pchook] $args]]
>  	}
>  
>  	return {}
>   

Re: git gui: Possible to see which commands are executed?

[Shawn O. Pearce]

Dirk Ssserott <newsletter@dirk.my1.cc> wrote:
> 
> thanks for your patch. Actually I had problems applying it and
> finally gave up. I'm using the msysGit package which seems quite
> similar to the cygwin package but not in all cases, apparently.

Well, msysGit is perhaps on an older version of git-gui.  But
I had thought they were fairly current and that the section of
code the patch touches hasn't been modified in a while.  Maybe
there was an issue with CRLF?
 
> However, you were right. The trace doesn't show the commands I
> would use on a regular basis (I couldn't stop you :-)).
> On the other hand it possibly helps to /understand/ (or at least
> /see/) what's going on under the hood.
> 
> For that reason I'd greatly appreciate seeing your patch in some
> future version of Git. It doesn't do any harm, does it? People
> that don't like it can simply omit the '--trace' switch.
> 
> Junio? The list?

Junio defers almost all git-gui things to me, as I am the current
maintainer of git-gui.  You are right, it doesn't really hurt to
include it, and now that it is written, the hard part is already
done.  I'll apply it to my main git-gui tree and ask Junio to
include it in a future version of Git.

-- 
Shawn.

Re: git gui: Possible to see which commands are executed?

[Sverre Rabbelier]

On Tue, May 20, 2008 at 9:44 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Junio defers almost all git-gui things to me, as I am the current
> maintainer of git-gui.  You are right, it doesn't really hurt to
> include it, and now that it is written, the hard part is already
> done.  I'll apply it to my main git-gui tree and ask Junio to
> include it in a future version of Git.

Hmmm, maybe you should include in big red letters that the output from
--trace in no way or form represents commands that a user should use
daily? I can hear the questions on #git already "I don't understand,
I've used git-gui for months now, but the command it tells me to use
make no sense!".
Even better of course would be to not only print the plumbing commands
but also the porcelain commands!

-- 
Cheers,

Sverre Rabbelier

Re: git gui: Possible to see which commands are executed?

[Dirk Süsserott]

Shawn O. Pearce schrieb:
> Dirk Ssserott <newsletter@dirk.my1.cc> wrote:
>   
>> thanks for your patch. Actually I had problems applying it and
>> finally gave up. I'm using the msysGit package which seems quite
>> similar to the cygwin package but not in all cases, apparently.
>>     
>
> Well, msysGit is perhaps on an older version of git-gui.  But
> I had thought they were fairly current and that the section of
> code the patch touches hasn't been modified in a while.  Maybe
> there was an issue with CRLF?
>   
Well, CRLF was one of the issues, but I fixed that with 'dos2unix'. At 
least I tried.
Don't bother. I had some problems with the filenames. git-gui.sh is in my
git-repo (git clone ...), whereas git-gui and git-gui.tcl are in my /bin 
directory.
I didn't know which to patch, tried them all, and copied them around.
As said, don't bother. It's just my stupidness.
>  
>   
>> However, you were right. The trace doesn't show the commands I
>> would use on a regular basis (I couldn't stop you :-)).
>> On the other hand it possibly helps to /understand/ (or at least
>> /see/) what's going on under the hood.
>>
>> For that reason I'd greatly appreciate seeing your patch in some
>> future version of Git. It doesn't do any harm, does it? People
>> that don't like it can simply omit the '--trace' switch.
>>
>> Junio? The list?
>>     
>
> Junio defers almost all git-gui things to me, as I am the current
> maintainer of git-gui.  You are right, it doesn't really hurt to
> include it, and now that it is written, the hard part is already
> done.  I'll apply it to my main git-gui tree and ask Junio to
> include it in a future version of Git.
>   
Great! Sorry, I didn't want to offend you. Wasn't aware that *you* are 
the git-gui maintainer.
Thanks. I'm looking forward to seeing this patch. :-)

    Dirk

Re: git gui: Possible to see which commands are executed?

[Shawn O. Pearce]

Sverre Rabbelier <alturin@gmail.com> wrote:
> On Tue, May 20, 2008 at 9:44 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Junio defers almost all git-gui things to me, as I am the current
> > maintainer of git-gui.  You are right, it doesn't really hurt to
> > include it, and now that it is written, the hard part is already
> > done.  I'll apply it to my main git-gui tree and ask Junio to
> > include it in a future version of Git.
> 
> Hmmm, maybe you should include in big red letters that the output from
> --trace in no way or form represents commands that a user should use
> daily?

Yea, probably.

> I can hear the questions on #git already "I don't understand,
> I've used git-gui for months now, but the command it tells me to use
> make no sense!".

Yup.  Or even worse, a user thinking that the best way to create a
new commit on the command line is the ugly sequence of:

	git-write-tree
	git-commit-tree ... -p ... <msg
	git-update-ref HEAD ...

Gee, that's like Git on the day when it became self-hosting and
Linus created commit e83c5163316f89bfbde7d9ab23ca2e25604af290
('Initial revision of "git", the information manager from hell').

> Even better of course would be to not only print the plumbing commands
> but also the porcelain commands!

That is probably difficult.  Some of the code internally is more
about stringing the right sequence of plumbing together than it
is about a particular user action.  I think it would take a bit of
work to make it do this, and I just don't see a reason to do it.

CVS clients that show CVS commands can easily do so, because they
are directly executing the commands they show you.  This is likely
also true of SVN commands.  But git-gui on Git, that's a whole
different animal.

-- 
Shawn.

Re: git gui: Possible to see which commands are executed?

[Sverre Rabbelier]

On Tue, May 20, 2008 at 10:17 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Yup.  Or even worse, a user thinking that the best way to create a
> new commit on the command line is the ugly sequence of:
>
>        git-write-tree
>        git-commit-tree ... -p ... <msg
>        git-update-ref HEAD ...
>

That would be awesome, no wait.. it wouldn't :P.

>> Even better of course would be to not only print the plumbing commands
>> but also the porcelain commands!
>
> That is probably difficult.  Some of the code internally is more
> about stringing the right sequence of plumbing together than it
> is about a particular user action.  I think it would take a bit of
> work to make it do this, and I just don't see a reason to do it.

The reason would be to make the switch from using git-gui only to
using the commandline too... the again, it'd be cutting your own hand
(or is it "throat" in English...) to make that transition easier.

> CVS clients that show CVS commands can easily do so, because they
> are directly executing the commands they show you.  This is likely
> also true of SVN commands.  But git-gui on Git, that's a whole
> different animal.

Ah, I didn't realise git-gui does stuff that you can't really do
through the regular porcelain. In that case it would indeed be
impossible to print the regular porcelain commands. I think the
'--trace' option should be advertised as 'debugging option' so that
the user can see what is going on in the case something goes wrong
perhaps?

-- 
Cheers,

Sverre Rabbelier

Re: git gui: Possible to see which commands are executed?

[Shawn O. Pearce]

Sverre Rabbelier <alturin@gmail.com> wrote:
> >
> > That is probably difficult.  Some of the code internally is more
> > about stringing the right sequence of plumbing together than it
> > is about a particular user action.  I think it would take a bit of
> > work to make it do this, and I just don't see a reason to do it.
> 
> The reason would be to make the switch from using git-gui only to
> using the commandline too... the again, it'd be cutting your own hand
> (or is it "throat" in English...) to make that transition easier.

I'm not worried about users leaving git-gui.  Hell, if git-gui
was just git on training wheels and all git users left git-gui
after a while for the command line that would be telling as it
says the graphical interface is not desired.  Or that git-gui's
interface is not well suited to the task.

Far from it.  Some users like git-gui for its ability to show
the modified files, and let you stage/unstage individual hunks.
Others like its ability to perform checkout+pull in one mouse
click.  Many like to point at things with a rodent than to use
the keyboard and enter (to them) isoteric commands.

Right now there are really only two git GUIs; git-gui and QGit.
Each has its strengths.  Maybe this time next year we will have
a 3rd; name yet to be determined but it would come out of the
egit/jgit project as a stand-alone SWT/Java based Git UI.
 
> > CVS clients that show CVS commands can easily do so, because they
> > are directly executing the commands they show you.  This is likely
> > also true of SVN commands.  But git-gui on Git, that's a whole
> > different animal.
> 
> Ah, I didn't realise git-gui does stuff that you can't really do
> through the regular porcelain. In that case it would indeed be
> impossible to print the regular porcelain commands. I think the
> '--trace' option should be advertised as 'debugging option' so that
> the user can see what is going on in the case something goes wrong
> perhaps?

Yes.  I'll send Junio a patch for Documentation/git-gui.txt and
describe it as a debugging option, and also mention that the commands
it displays aren't all meant to be invoked by mortals.

-- 
Shawn.

Re: git gui: Possible to see which commands are executed?

[Sverre Rabbelier]

On Tue, May 20, 2008 at 10:31 PM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Far from it.  Some users like git-gui for its ability to show
> the modified files, and let you stage/unstage individual hunks.
> Others like its ability to perform checkout+pull in one mouse
> click.  Many like to point at things with a rodent than to use
> the keyboard and enter (to them) isoteric commands.

Heh, I've never understood that, but I have a classmate that won't
touch anything that doesn't have a "shiney" GUI that he likes (that
is, he'll prefer the program with a "shiney" GUI even if there is one
without that has better features).

> Right now there are really only two git GUIs; git-gui and QGit.
> Each has its strengths.  Maybe this time next year we will have
> a 3rd; name yet to be determined but it would come out of the
> egit/jgit project as a stand-alone SWT/Java based Git UI.

Is it "shiney"? If you haven't already, look into applying a theme to
the app, the Substance LAF definitely looks "shiney"!

> Yes.  I'll send Junio a patch for Documentation/git-gui.txt and
> describe it as a debugging option, and also mention that the commands
> it displays aren't all meant to be invoked by mortals.

Sounds like a plan (maybe use "mere mortals" instead ;), it's more cool).

-- 
Cheers,

Sverre Rabbelier

Re: git gui: Possible to see which commands are executed?

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Sverre Rabbelier <alturin@gmail.com> wrote:
>> >
>> > That is probably difficult.  Some of the code internally is more
>> > about stringing the right sequence of plumbing together than it
>> > is about a particular user action.  I think it would take a bit of
>> > work to make it do this, and I just don't see a reason to do it.
>> 
>> The reason would be to make the switch from using git-gui only to
>> using the commandline too... the again, it'd be cutting your own hand
>> (or is it "throat" in English...) to make that transition easier.
>
> I'm not worried about users leaving git-gui.  Hell, if git-gui
> was just git on training wheels and all git users left git-gui
> after a while for the command line that would be telling as it
> says the graphical interface is not desired.  Or that git-gui's
> interface is not well suited to the task.
>
> Far from it.  Some users like git-gui for its ability to show
> the modified files, and let you stage/unstage individual hunks.
> Others like its ability to perform checkout+pull in one mouse
> click.  Many like to point at things with a rodent than to use
> the keyboard and enter (to them) isoteric commands.
>
> Right now there are really only two git GUIs; git-gui and QGit.
> Each has its strengths.  Maybe this time next year we will have
> a 3rd; name yet to be determined but it would come out of the
> egit/jgit project as a stand-alone SWT/Java based Git UI.
>  
>> > CVS clients that show CVS commands can easily do so, because they
>> > are directly executing the commands they show you.  This is likely
>> > also true of SVN commands.  But git-gui on Git, that's a whole
>> > different animal.
>> 
>> Ah, I didn't realise git-gui does stuff that you can't really do
>> through the regular porcelain. In that case it would indeed be
>> impossible to print the regular porcelain commands. I think the
>> '--trace' option should be advertised as 'debugging option' so that
>> the user can see what is going on in the case something goes wrong
>> perhaps?
>
> Yes.  I'll send Junio a patch for Documentation/git-gui.txt and
> describe it as a debugging option, and also mention that the commands
> it displays aren't all meant to be invoked by mortals.

Probably --trace should be renamed to --debug then?

Re: git gui: Possible to see which commands are executed?

[Shawn O. Pearce]

Junio C Hamano <gitster@pobox.com> wrote:
> > Sverre Rabbelier <alturin@gmail.com> wrote:
> >> 
> >> Ah, I didn't realise git-gui does stuff that you can't really do
> >> through the regular porcelain. In that case it would indeed be
> >> impossible to print the regular porcelain commands. I think the
> >> '--trace' option should be advertised as 'debugging option' so that
> >> the user can see what is going on in the case something goes wrong
> >> perhaps?
> 
> Probably --trace should be renamed to --debug then?

Well, we do have GIT_TRACE, and git-gui --trace is sort of the
same idea.  :-)

I was going to call it --debug, but went with --trace as it is
closer to GIT_TRACE than it is to say git-describe --debug.

-- 
Shawn.

Re: git gui: Possible to see which commands are executed?

[Johannes Schindelin]

Hi,

On Tue, 20 May 2008, Shawn O. Pearce wrote:

> Junio C Hamano <gitster@pobox.com> wrote:
> > > Sverre Rabbelier <alturin@gmail.com> wrote:
> > >> 
> > >> Ah, I didn't realise git-gui does stuff that you can't really do
> > >> through the regular porcelain. In that case it would indeed be
> > >> impossible to print the regular porcelain commands. I think the
> > >> '--trace' option should be advertised as 'debugging option' so that
> > >> the user can see what is going on in the case something goes wrong
> > >> perhaps?
> > 
> > Probably --trace should be renamed to --debug then?
> 
> Well, we do have GIT_TRACE, and git-gui --trace is sort of the
> same idea.  :-)

Which brings me to the suggestion to reuse GIT_TRACE instead of adding 
an option...

Ciao,
Dscho

Re: git gui: Possible to see which commands are executed?

[Karl Hasselström]

On 2008-05-21 09:30:39 +0100, Johannes Schindelin wrote:

> On Tue, 20 May 2008, Shawn O. Pearce wrote:
>
> > Junio C Hamano <gitster@pobox.com> wrote:
> >
> > > Probably --trace should be renamed to --debug then?
> >
> > Well, we do have GIT_TRACE, and git-gui --trace is sort of the
> > same idea. :-)
>
> Which brings me to the suggestion to reuse GIT_TRACE instead of
> adding an option...

FWIW, StGit uses STGIT_SUBPROCESS_LOG for this purpose. (Can be set to
"debug" to get maximum details, or "profile" to get the time of each
subprocess call.)

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: git gui: Possible to see which commands are executed?

[Shawn O. Pearce]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 20 May 2008, Shawn O. Pearce wrote:
> > 
> > Well, we do have GIT_TRACE, and git-gui --trace is sort of the
> > same idea.  :-)
> 
> Which brings me to the suggestion to reuse GIT_TRACE instead of adding 
> an option...

Well... you may not want to see what GIT_TRACE causes, but you
do want to see what `git gui --trace` gives you.  So I didn't
want to overload it.

-- 
Shawn.

Re: git gui: Possible to see which commands are executed?

[Nigel Magnay]

> I'm not worried about users leaving git-gui.  Hell, if git-gui
> was just git on training wheels and all git users left git-gui
> after a while for the command line that would be telling as it
> says the graphical interface is not desired.  Or that git-gui's
> interface is not well suited to the task.
>
> Far from it.  Some users like git-gui for its ability to show
> the modified files, and let you stage/unstage individual hunks.
> Others like its ability to perform checkout+pull in one mouse
> click.  Many like to point at things with a rodent than to use
> the keyboard and enter (to them) isoteric commands.
>
> Right now there are really only two git GUIs; git-gui and QGit.
> Each has its strengths.  Maybe this time next year we will have
> a 3rd; name yet to be determined but it would come out of the
> egit/jgit project as a stand-alone SWT/Java based Git UI.
>

I have to say - git is the first SCM that I've used that commandline
usage is actually pleasant in - so much so, the lack of easy cut&paste
from 'git status' in colleagues cygwin windows becomes a serious pain!

git-gui is good though - but there's a few things I wish it had. I
often find the need to flip between git gui and gitk (for a 'where the
heck am I at the moment' overview) - the 2 tools seems to confuse
people coming at git, even given 'visualize branch'. It'd be nice to
be able to add files / directories to .gitignore, and to view the
staged/unstaged changes as trees - helpful for when a build has
created a non-ignored directory with thousands of files. Maybe I
should get qgit - but git gui has the massive advantage of being in
every install by default, and so is available in msysgit.

Whilst I'm thinking about it - I'm surprised in retrospect how little
prominence the index is given in the frontends I've seen. It's easy,
coming from SVN, to gloss over the index as the same as just checking
off files at commit time, and miss stuff like 'git add --patch' and
'git mergetool' altogether.

Re: git gui: Possible to see which commands are executed?

[Shawn O. Pearce]

Nigel Magnay <nigel.magnay@gmail.com> wrote:
> 
> git-gui is good though - but there's a few things I wish it had. I
> often find the need to flip between git gui and gitk (for a 'where the
> heck am I at the moment' overview) - the 2 tools seems to confuse
> people coming at git, even given 'visualize branch'.

Yup.  I haven't tried to reimplement a visualizer in git-gui, nor
have I tried to embed gitk into git-gui.  Both would take a great
deal of work I think (though embedding gitk is likely easier) and I
just have too many things going on to pursue this myself.  If someone
showed patches for this, I'd definately try to get them included.

> It'd be nice to
> be able to add files / directories to .gitignore,

Always been a "wishlist" feature for git-gui.  Paul Mackerras' gitool
prototype (which is what seeded git-gui) had this feature, but it was
never carried into git-gui.  Again, patches welcome.  :-)

> and to view the
> staged/unstaged changes as trees - helpful for when a build has
> created a non-ignored directory with thousands of files.

Yea.  And when that happens to me I immediately slap the directory
into my .gitignore or .git/info/exclude and rescan to make the huge
pile of untracked files disappear.  So a tree view in git-gui has
never been something I wanted.  Trees in Tcl/Tk are also horrible
to implement.  The toolkit just has never been very good at that
sort of thing.

> Maybe I
> should get qgit - but git gui has the massive advantage of being in
> every install by default, and so is available in msysgit.

Yes, I have to admit that git-gui's popularity among git users has a
_lot_ to do with the simple fact that it ships out of the box as part
of Junio's git releases.  Since most git users have Tcl/Tk available
so they can use gitk, git-gui is also ready-to-go, with no extra libs
needed on your system.

However, QGit is also a good program, and has many loyal users.
There are benefits and drawbacks to both GUIs.
 
> Whilst I'm thinking about it - I'm surprised in retrospect how little
> prominence the index is given in the frontends I've seen.

Really?  git-gui is all about the index.

> It's easy,
> coming from SVN, to gloss over the index as the same as just checking
> off files at commit time, and miss stuff like 'git add --patch' and
> 'git mergetool' altogether.

Right click on a hunk in the diff pane in git-gui and stage/unstage
it?  Its about as good as `git add --patch`.  Or better, depending
on how you work.

-- 
Shawn.