{"thread":{"id":"13565","subject":"git gui: Possible to see which commands are executed?","startedAt":"2008-05-18T12:03:35Z","lastAt":"2008-05-22T23:05:45Z","messageCount":19,"participants":["Dirk Süsserott","Miklos Vajna","Shawn O. Pearce","Sverre Rabbelier","Junio C Hamano","Johannes Schindelin","Karl Hasselström","Nigel Magnay"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"77223","messageId":"48301B17.30309@dirk.my1.cc","threadId":"13565","inReplyTo":null,"subject":"git gui: Possible to see which commands are executed?","fromName":"Dirk Süsserott","fromEmail":"newsletter@dirk.my1.cc","sentAt":"2008-05-18T12:03:35Z","receivedAt":"2008-05-18T12:03:35Z","isPatch":false,"sender":{"key":"newsletter@dirk.my1.cc","avatar":null},"body":"Is it possible to see which commands are executed by git-gui?\nFor an example, there's a menu item \"branch -> rename\".\nI'm not aware that such a thing as \"git branch rename\"\nexists on the command line. So git-gui must do it by\nother means. Is there a way to see how? (Don't stick with\nthis example, it's a general question.)\nSome \"--debug\" or \"--log\" switch which logs the\ncommands to a logfile or so? I know I could examine the\nsources but that's not convenient ;-)\n\nIt would be really cool when git-gui could show the command\nin a different window *before* it is executed. Some database\nfrontends have an option \"show SQL statement\", but I think\nthat would be demanded too much.\n\n Dirk\n"},{"id":"77224","messageId":"20080518121349.GE27724@genesis.frugalware.org","threadId":"13565","inReplyTo":"48301B17.30309@dirk.my1.cc","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Miklos Vajna","fromEmail":"vmiklos@frugalware.org","sentAt":"2008-05-18T12:13:49Z","receivedAt":"2008-05-18T12:13:49Z","isPatch":false,"sender":{"key":"vmiklos@frugalware.org","avatar":"https://gravatar.com/avatar/401c1cbbb3a5d13e650c691a2c71d6fd0b80df1a01bc74d9f1972675dd58f2bd?d=mp&s=160"},"body":"On Sun, May 18, 2008 at 02:03:35PM +0200, Dirk Süsserott wrote:\n> I'm not aware that such a thing as \"git branch rename\"\n> exists on the command line.\n\nman git-branch, search for rename:\n\n\"With a -m or -M option, will be renamed to .\"\n"},{"id":"77225","messageId":"4830225D.5050605@suesserott.de","threadId":"13565","inReplyTo":"20080518121349.GE27724@genesis.frugalware.org","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Dirk Süsserott","fromEmail":"poststelle@suesserott.de","sentAt":"2008-05-18T12:34:37Z","receivedAt":"2008-05-18T12:34:37Z","isPatch":false,"sender":{"key":"poststelle@suesserott.de","avatar":null},"body":"Miklos Vajna schrieb:\n> On Sun, May 18, 2008 at 02:03:35PM +0200, Dirk Süsserott wrote:\n> \n>> I'm not aware that such a thing as \"git branch rename\"\n>> exists on the command line.\n>> \n>\n> man git-branch, search for rename:\n>\n> \"With a -m or -M option, will be renamed to .\"\n> \nThanks. Ok, I missed that \"rename branch\" switch :-(. But that was just \nan example.\nI'm actually looking for a 'git gui --log' switch to show me your very \nanswer.\n"},{"id":"77245","messageId":"20080519022125.GV29038@spearce.org","threadId":"13565","inReplyTo":"48301B17.30309@dirk.my1.cc","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-05-19T02:21:25Z","receivedAt":"2008-05-19T02:21:25Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Dirk Ssserott wrote:\n> Is it possible to see which commands are executed by git-gui?\n...\n> It would be really cool when git-gui could show the command\n> in a different window *before* it is executed. Some database\n> frontends have an option \"show SQL statement\", but I think\n> that would be demanded too much.\n\nNot presently, no. People have asked for this in the past, but\nits not as easy as it sounds. git-gui tries to drive the plumbing\ncommands when possible, not the porcelain that most humans use.\nConsequently the stream of commands that git-gui issues is quite\ndifferent from what a human would type on the command line, yet\nthe end result is equivilant.\n\nI hacked this up earlier today on my Cygwin system, just to show you\nwhat I mean. With the attached patch applied I restarted git-gui\nwith `git gui --trace` (which this patch introduces) and then used\ngit-gui to commit this patch to its own repository.\n\nStop me when you see a command you might type yourself. ;-)\n\n C:/cygwin/usr/local/git/bin/git.exe --version\n < git version 1.5.5.1.450.gee27\n C:/cygwin/usr/local/git/bin/git.exe --exec-path\n < /usr/local/git/bin\n C:/cygwin/usr/local/git/bin/git-rev-parse.exe --git-dir\n < .git\n C:/cygwin/usr/local/git/bin/git-rev-parse.exe --show-prefix\n < \n C:/cygwin/usr/local/git/bin/git-config.exe --null --list\n C:/cygwin/usr/local/git/bin/git-rev-parse.exe --verify HEAD\n < 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7\n C:/cygwin/usr/local/git/bin/git-update-index.exe -q --unmerged --ignore-missing --refresh\n C:/cygwin/usr/local/git/bin/git-diff-index.exe --cached -z 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7\n C:/cygwin/usr/local/git/bin/git-diff-files.exe -z\n C:/cygwin/usr/local/git/bin/git-ls-files.exe --others -z --exclude-per-directory=.gitignore --exclude-from=.git/info/exclude\n C:/cygwin/usr/local/git/bin/git-rev-parse.exe --verify HEAD\n < 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7\n C:/cygwin/usr/local/git/bin/git-update-index.exe -q --unmerged --ignore-missing --refresh\n C:/cygwin/usr/local/git/bin/git-diff-index.exe --cached -z 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7\n C:/cygwin/usr/local/git/bin/git-diff-files.exe -z\n C:/cygwin/usr/local/git/bin/git-ls-files.exe --others -z --exclude-per-directory=.gitignore --exclude-from=.git/info/exclude\n C:/cygwin/usr/local/git/bin/git-update-index.exe --add --remove -z --stdin\n C:/cygwin/usr/local/git/bin/git-var.exe GIT_COMMITTER_IDENT\n < Shawn O. Pearce 1211130496 -0400\n C:/cygwin/usr/local/git/bin/git-rev-parse.exe --verify HEAD\n < 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7\n C:/cygwin/bin/sh.exe -c 'if test -x \"$1\";then exec \"$@\";fi'\n C:/cygwin/bin/sh.exe .git/hooks/pre-commit 2>@1\n C:/cygwin/bin/sh.exe -c 'if test -x \"$1\";then exec \"$@\";fi'\n C:/cygwin/bin/sh.exe .git/hooks/commit-msg .git/GITGUI_EDITMSG 2>@1\n C:/cygwin/usr/local/git/bin/git-write-tree.exe\n C:/cygwin/usr/local/git/bin/git-cat-file.exe commit 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7\n C:/cygwin/usr/local/git/bin/git-commit-tree.exe 26a475c0a74f51872513993c41e8e15286df9fa5 -p 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7 <.git/GITGUI_EDITMSG\n < cc33ff6ec3582522edaae00354d9b96a797ecf09\n C:/cygwin/usr/local/git/bin/git-update-ref.exe -m 'commit: git-gui: Add a --trace command line option' HEAD cc33ff6ec3582522edaae00354d9b96a797ecf09 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7\n < \n C:/cygwin/bin/sh.exe -c 'if test -x \"$1\";then exec \"$@\";fi'\n C:/cygwin/bin/sh.exe .git/hooks/post-commit 2>@1\n\nRight. So I'm not certain how useful this patch really is. It is\nfairly short as all calls to git go through one of three procedures.\n\n\n--8<--\ngit-gui: Add a --trace command line option\n\n---\n git-gui.sh | 47 +++++++++++++++++++++++++++++++++++++++--------\n 1 files changed, 39 insertions(+), 8 deletions(-)\n\ndiff --git a/git-gui.sh b/git-gui.sh\nindex 9df4971..6a8831a 100755\n--- a/git-gui.sh\n+++ b/git-gui.sh\n@@ -122,6 +122,14 @@ set _reponame {}\n set _iscygwin {}\n set _search_path {}\n \n+set _trace [lsearch -exact $argv --trace]\n+if {$_trace >= 0} {\n+\tset argv [lreplace $argv $_trace $_trace]\n+\tset _trace 1\n+} else {\n+\tset _trace 0\n+}\n+\n proc appname {} {\n \tglobal _appname\n \treturn $_appname\n@@ -245,6 +253,21 @@ proc get_config {name} {\n ##\n ## handy utils\n \n+proc _trace_exec {cmd} {\n+\tif {!$::_trace} return\n+\tset d {}\n+\tforeach v $cmd {\n+\t\tif {$d ne {}} {\n+\t\t\tappend d { }\n+\t\t}\n+\t\tif {[regexp {[ \\t\\r\\n'\"$?*]} $v]} {\n+\t\t\tset v [sq $v]\n+\t\t}\n+\t\tappend d $v\n+\t}\n+\tputs stderr $d\n+}\n+\n proc _git_cmd {name} {\n \tglobal _git_cmd_path\n \n@@ -339,7 +362,7 @@ proc _lappend_nice {cmd_var} {\n }\n \n proc git {args} {\n-\tset opt [list exec]\n+\tset opt [list]\n \n \twhile {1} {\n \t\tswitch -- [lindex $args 0] {\n@@ -359,12 +382,18 @@ proc git {args} {\n \tset cmdp [_git_cmd [lindex $args 0]]\n \tset args [lrange $args 1 end]\n \n-\treturn [eval $opt $cmdp $args]\n+\t_trace_exec [concat $opt $cmdp $args]\n+\tset result [eval exec $opt $cmdp $args]\n+\tif {$::_trace} {\n+\t\tputs stderr \"< $result\"\n+\t}\n+\treturn $result\n }\n \n proc _open_stdout_stderr {cmd} {\n+\t_trace_exec $cmd\n \tif {[catch {\n-\t\t\tset fd [open $cmd r]\n+\t\t\tset fd [open [concat [list | ] $cmd] r]\n \t\t} err]} {\n \t\tif { [lindex $cmd end] eq {2>@1}\n \t\t && $err eq {can not find channel named \"1\"}\n@@ -375,6 +404,7 @@ proc _open_stdout_stderr {cmd} {\n \t\t\t# to try to start it a second time.\n \t\t\t#\n \t\t\tset fd [open [concat \\\n+\t\t\t\t[list | ] \\\n \t\t\t\t[lrange $cmd 0 end-1] \\\n \t\t\t\t[list |& cat] \\\n \t\t\t\t] r]\n@@ -387,7 +417,7 @@ proc _open_stdout_stderr {cmd} {\n }\n \n proc git_read {args} {\n-\tset opt [list |]\n+\tset opt [list]\n \n \twhile {1} {\n \t\tswitch -- [lindex $args 0] {\n@@ -415,7 +445,7 @@ proc git_read {args} {\n }\n \n proc git_write {args} {\n-\tset opt [list |]\n+\tset opt [list]\n \n \twhile {1} {\n \t\tswitch -- [lindex $args 0] {\n@@ -435,7 +465,8 @@ proc git_write {args} {\n \tset cmdp [_git_cmd [lindex $args 0]]\n \tset args [lrange $args 1 end]\n \n-\treturn [open [concat $opt $cmdp $args] w]\n+\t_trace_exec [concat $opt $cmdp $args]\n+\treturn [open [concat [list | ] $opt $cmdp $args] w]\n }\n \n proc githook_read {hook_name args} {\n@@ -455,12 +486,12 @@ proc githook_read {hook_name args} {\n \t\t}\n \n \t\tset scr {if test -x \"$1\";then exec \"$@\";fi}\n-\t\tset sh_c [list | $interp -c $scr $interp $pchook]\n+\t\tset sh_c [list $interp -c $scr $interp $pchook]\n \t\treturn [_open_stdout_stderr [concat $sh_c $args]]\n \t}\n \n \tif {[file executable $pchook]} {\n-\t\treturn [_open_stdout_stderr [concat [list | $pchook] $args]]\n+\t\treturn [_open_stdout_stderr [concat [list $pchook] $args]]\n \t}\n \n \treturn {}\n-- \n1.5.5.1.450.gee27\n\n\n-- \nShawn.\n"},{"id":"77332","messageId":"4833206E.1080300@dirk.my1.cc","threadId":"13565","inReplyTo":"20080519022125.GV29038@spearce.org","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Dirk Süsserott","fromEmail":"newsletter@dirk.my1.cc","sentAt":"2008-05-20T19:03:10Z","receivedAt":"2008-05-20T19:03:10Z","isPatch":false,"sender":{"key":"newsletter@dirk.my1.cc","avatar":null},"body":"Shawn O. Pearce schrieb:\n> Dirk Ssserott wrote:\n> \n>> Is it possible to see which commands are executed by git-gui?\n>> \n> ...\n> \n>> It would be really cool when git-gui could show the command\n>> in a different window *before* it is executed. Some database\n>> frontends have an option \"show SQL statement\", but I think\n>> that would be demanded too much.\n>> \n>\n> Not presently, no. People have asked for this in the past, but\n> its not as easy as it sounds. git-gui tries to drive the plumbing\n> commands when possible, not the porcelain that most humans use.\n> Consequently the stream of commands that git-gui issues is quite\n> different from what a human would type on the command line, yet\n> the end result is equivilant.\n>\n> I hacked this up earlier today on my Cygwin system, just to show you\n> what I mean. With the attached patch applied I restarted git-gui\n> with `git gui --trace` (which this patch introduces) and then used\n> git-gui to commit this patch to its own repository.\n>\n> Stop me when you see a command you might type yourself. ;-)\n> \n\nHi Shawn,\n\nthanks for your patch. Actually I had problems applying it and\nfinally gave up. I'm using the msysGit package which seems quite\nsimilar to the cygwin package but not in all cases, apparently.\n\nHowever, you were right. The trace doesn't show the commands I\nwould use on a regular basis (I couldn't stop you :-)).\nOn the other hand it possibly helps to /understand/ (or at least\n/see/) what's going on under the hood.\n\nFor that reason I'd greatly appreciate seeing your patch in some\nfuture version of Git. It doesn't do any harm, does it? People\nthat don't like it can simply omit the '--trace' switch.\n\nJunio? The list?\n\n Dirk\n\n> C:/cygwin/usr/local/git/bin/git.exe --version\n> < git version 1.5.5.1.450.gee27\n> C:/cygwin/usr/local/git/bin/git.exe --exec-path\n> < /usr/local/git/bin\n> C:/cygwin/usr/local/git/bin/git-rev-parse.exe --git-dir\n> < .git\n> C:/cygwin/usr/local/git/bin/git-rev-parse.exe --show-prefix\n> < \n> C:/cygwin/usr/local/git/bin/git-config.exe --null --list\n> C:/cygwin/usr/local/git/bin/git-rev-parse.exe --verify HEAD\n> < 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7\n> C:/cygwin/usr/local/git/bin/git-update-index.exe -q --unmerged --ignore-missing --refresh\n> C:/cygwin/usr/local/git/bin/git-diff-index.exe --cached -z 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7\n> C:/cygwin/usr/local/git/bin/git-diff-files.exe -z\n> C:/cygwin/usr/local/git/bin/git-ls-files.exe --others -z --exclude-per-directory=.gitignore --exclude-from=.git/info/exclude\n> C:/cygwin/usr/local/git/bin/git-rev-parse.exe --verify HEAD\n> < 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7\n> C:/cygwin/usr/local/git/bin/git-update-index.exe -q --unmerged --ignore-missing --refresh\n> C:/cygwin/usr/local/git/bin/git-diff-index.exe --cached -z 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7\n> C:/cygwin/usr/local/git/bin/git-diff-files.exe -z\n> C:/cygwin/usr/local/git/bin/git-ls-files.exe --others -z --exclude-per-directory=.gitignore --exclude-from=.git/info/exclude\n> C:/cygwin/usr/local/git/bin/git-update-index.exe --add --remove -z --stdin\n> C:/cygwin/usr/local/git/bin/git-var.exe GIT_COMMITTER_IDENT\n> < Shawn O. Pearce 1211130496 -0400\n> C:/cygwin/usr/local/git/bin/git-rev-parse.exe --verify HEAD\n> < 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7\n> C:/cygwin/bin/sh.exe -c 'if test -x \"$1\";then exec \"$@\";fi'\n> C:/cygwin/bin/sh.exe .git/hooks/pre-commit 2>@1\n> C:/cygwin/bin/sh.exe -c 'if test -x \"$1\";then exec \"$@\";fi'\n> C:/cygwin/bin/sh.exe .git/hooks/commit-msg .git/GITGUI_EDITMSG 2>@1\n> C:/cygwin/usr/local/git/bin/git-write-tree.exe\n> C:/cygwin/usr/local/git/bin/git-cat-file.exe commit 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7\n> C:/cygwin/usr/local/git/bin/git-commit-tree.exe 26a475c0a74f51872513993c41e8e15286df9fa5 -p 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7 <.git/GITGUI_EDITMSG\n> < cc33ff6ec3582522edaae00354d9b96a797ecf09\n> C:/cygwin/usr/local/git/bin/git-update-ref.exe -m 'commit: git-gui: Add a --trace command line option' HEAD cc33ff6ec3582522edaae00354d9b96a797ecf09 76bb40cde0e15e8d0e8493abb0bd18a5d6386ad7\n> < \n> C:/cygwin/bin/sh.exe -c 'if test -x \"$1\";then exec \"$@\";fi'\n> C:/cygwin/bin/sh.exe .git/hooks/post-commit 2>@1\n>\n> Right. So I'm not certain how useful this patch really is. It is\n> fairly short as all calls to git go through one of three procedures.\n>\n>\n> --8<--\n> git-gui: Add a --trace command line option\n>\n> ---\n> git-gui.sh | 47 +++++++++++++++++++++++++++++++++++++++--------\n> 1 files changed, 39 insertions(+), 8 deletions(-)\n>\n> diff --git a/git-gui.sh b/git-gui.sh\n> index 9df4971..6a8831a 100755\n> --- a/git-gui.sh\n> +++ b/git-gui.sh\n> @@ -122,6 +122,14 @@ set _reponame {}\n> set _iscygwin {}\n> set _search_path {}\n> \n> +set _trace [lsearch -exact $argv --trace]\n> +if {$_trace >= 0} {\n> +\tset argv [lreplace $argv $_trace $_trace]\n> +\tset _trace 1\n> +} else {\n> +\tset _trace 0\n> +}\n> +\n> proc appname {} {\n> \tglobal _appname\n> \treturn $_appname\n> @@ -245,6 +253,21 @@ proc get_config {name} {\n> ##\n> ## handy utils\n> \n> +proc _trace_exec {cmd} {\n> +\tif {!$::_trace} return\n> +\tset d {}\n> +\tforeach v $cmd {\n> +\t\tif {$d ne {}} {\n> +\t\t\tappend d { }\n> +\t\t}\n> +\t\tif {[regexp {[ \\t\\r\\n'\"$?*]} $v]} {\n> +\t\t\tset v [sq $v]\n> +\t\t}\n> +\t\tappend d $v\n> +\t}\n> +\tputs stderr $d\n> +}\n> +\n> proc _git_cmd {name} {\n> \tglobal _git_cmd_path\n> \n> @@ -339,7 +362,7 @@ proc _lappend_nice {cmd_var} {\n> }\n> \n> proc git {args} {\n> -\tset opt [list exec]\n> +\tset opt [list]\n> \n> \twhile {1} {\n> \t\tswitch -- [lindex $args 0] {\n> @@ -359,12 +382,18 @@ proc git {args} {\n> \tset cmdp [_git_cmd [lindex $args 0]]\n> \tset args [lrange $args 1 end]\n> \n> -\treturn [eval $opt $cmdp $args]\n> +\t_trace_exec [concat $opt $cmdp $args]\n> +\tset result [eval exec $opt $cmdp $args]\n> +\tif {$::_trace} {\n> +\t\tputs stderr \"< $result\"\n> +\t}\n> +\treturn $result\n> }\n> \n> proc _open_stdout_stderr {cmd} {\n> +\t_trace_exec $cmd\n> \tif {[catch {\n> -\t\t\tset fd [open $cmd r]\n> +\t\t\tset fd [open [concat [list | ] $cmd] r]\n> \t\t} err]} {\n> \t\tif { [lindex $cmd end] eq {2>@1}\n> \t\t && $err eq {can not find channel named \"1\"}\n> @@ -375,6 +404,7 @@ proc _open_stdout_stderr {cmd} {\n> \t\t\t# to try to start it a second time.\n> \t\t\t#\n> \t\t\tset fd [open [concat \\\n> +\t\t\t\t[list | ] \\\n> \t\t\t\t[lrange $cmd 0 end-1] \\\n> \t\t\t\t[list |& cat] \\\n> \t\t\t\t] r]\n> @@ -387,7 +417,7 @@ proc _open_stdout_stderr {cmd} {\n> }\n> \n> proc git_read {args} {\n> -\tset opt [list |]\n> +\tset opt [list]\n> \n> \twhile {1} {\n> \t\tswitch -- [lindex $args 0] {\n> @@ -415,7 +445,7 @@ proc git_read {args} {\n> }\n> \n> proc git_write {args} {\n> -\tset opt [list |]\n> +\tset opt [list]\n> \n> \twhile {1} {\n> \t\tswitch -- [lindex $args 0] {\n> @@ -435,7 +465,8 @@ proc git_write {args} {\n> \tset cmdp [_git_cmd [lindex $args 0]]\n> \tset args [lrange $args 1 end]\n> \n> -\treturn [open [concat $opt $cmdp $args] w]\n> +\t_trace_exec [concat $opt $cmdp $args]\n> +\treturn [open [concat [list | ] $opt $cmdp $args] w]\n> }\n> \n> proc githook_read {hook_name args} {\n> @@ -455,12 +486,12 @@ proc githook_read {hook_name args} {\n> \t\t}\n> \n> \t\tset scr {if test -x \"$1\";then exec \"$@\";fi}\n> -\t\tset sh_c [list | $interp -c $scr $interp $pchook]\n> +\t\tset sh_c [list $interp -c $scr $interp $pchook]\n> \t\treturn [_open_stdout_stderr [concat $sh_c $args]]\n> \t}\n> \n> \tif {[file executable $pchook]} {\n> -\t\treturn [_open_stdout_stderr [concat [list | $pchook] $args]]\n> +\t\treturn [_open_stdout_stderr [concat [list $pchook] $args]]\n> \t}\n> \n> \treturn {}\n> \n"},{"id":"77333","messageId":"20080520194403.GC29038@spearce.org","threadId":"13565","inReplyTo":"4833206E.1080300@dirk.my1.cc","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-05-20T19:44:03Z","receivedAt":"2008-05-20T19:44:03Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Dirk Ssserott wrote:\n> \n> thanks for your patch. Actually I had problems applying it and\n> finally gave up. I'm using the msysGit package which seems quite\n> similar to the cygwin package but not in all cases, apparently.\n\nWell, msysGit is perhaps on an older version of git-gui. But\nI had thought they were fairly current and that the section of\ncode the patch touches hasn't been modified in a while. Maybe\nthere was an issue with CRLF?\n \n> However, you were right. The trace doesn't show the commands I\n> would use on a regular basis (I couldn't stop you :-)).\n> On the other hand it possibly helps to /understand/ (or at least\n> /see/) what's going on under the hood.\n> \n> For that reason I'd greatly appreciate seeing your patch in some\n> future version of Git. It doesn't do any harm, does it? People\n> that don't like it can simply omit the '--trace' switch.\n> \n> Junio? The list?\n\nJunio defers almost all git-gui things to me, as I am the current\nmaintainer of git-gui. You are right, it doesn't really hurt to\ninclude it, and now that it is written, the hard part is already\ndone. I'll apply it to my main git-gui tree and ask Junio to\ninclude it in a future version of Git.\n\n-- \nShawn.\n"},{"id":"77335","messageId":"bd6139dc0805201305k61807561k8026b4c6509e4041@mail.gmail.com","threadId":"13565","inReplyTo":"20080520194403.GC29038@spearce.org","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-05-20T20:05:20Z","receivedAt":"2008-05-20T20:05:20Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Tue, May 20, 2008 at 9:44 PM, Shawn O. Pearce wrote:\n> Junio defers almost all git-gui things to me, as I am the current\n> maintainer of git-gui. You are right, it doesn't really hurt to\n> include it, and now that it is written, the hard part is already\n> done. I'll apply it to my main git-gui tree and ask Junio to\n> include it in a future version of Git.\n\nHmmm, maybe you should include in big red letters that the output from\n--trace in no way or form represents commands that a user should use\ndaily? I can hear the questions on #git already \"I don't understand,\nI've used git-gui for months now, but the command it tells me to use\nmake no sense!\".\nEven better of course would be to not only print the plumbing commands\nbut also the porcelain commands!\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"77337","messageId":"4833309B.90706@dirk.my1.cc","threadId":"13565","inReplyTo":"20080520194403.GC29038@spearce.org","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Dirk Süsserott","fromEmail":"newsletter@dirk.my1.cc","sentAt":"2008-05-20T20:12:11Z","receivedAt":"2008-05-20T20:12:11Z","isPatch":false,"sender":{"key":"newsletter@dirk.my1.cc","avatar":null},"body":"Shawn O. Pearce schrieb:\n> Dirk Ssserott wrote:\n> \n>> thanks for your patch. Actually I had problems applying it and\n>> finally gave up. I'm using the msysGit package which seems quite\n>> similar to the cygwin package but not in all cases, apparently.\n>> \n>\n> Well, msysGit is perhaps on an older version of git-gui. But\n> I had thought they were fairly current and that the section of\n> code the patch touches hasn't been modified in a while. Maybe\n> there was an issue with CRLF?\n> \nWell, CRLF was one of the issues, but I fixed that with 'dos2unix'. At \nleast I tried.\nDon't bother. I had some problems with the filenames. git-gui.sh is in my\ngit-repo (git clone ...), whereas git-gui and git-gui.tcl are in my /bin \ndirectory.\nI didn't know which to patch, tried them all, and copied them around.\nAs said, don't bother. It's just my stupidness.\n> \n> \n>> However, you were right. The trace doesn't show the commands I\n>> would use on a regular basis (I couldn't stop you :-)).\n>> On the other hand it possibly helps to /understand/ (or at least\n>> /see/) what's going on under the hood.\n>>\n>> For that reason I'd greatly appreciate seeing your patch in some\n>> future version of Git. It doesn't do any harm, does it? People\n>> that don't like it can simply omit the '--trace' switch.\n>>\n>> Junio? The list?\n>> \n>\n> Junio defers almost all git-gui things to me, as I am the current\n> maintainer of git-gui. You are right, it doesn't really hurt to\n> include it, and now that it is written, the hard part is already\n> done. I'll apply it to my main git-gui tree and ask Junio to\n> include it in a future version of Git.\n> \nGreat! Sorry, I didn't want to offend you. Wasn't aware that *you* are \nthe git-gui maintainer.\nThanks. I'm looking forward to seeing this patch. :-)\n\n Dirk\n"},{"id":"77339","messageId":"20080520201722.GF29038@spearce.org","threadId":"13565","inReplyTo":"bd6139dc0805201305k61807561k8026b4c6509e4041@mail.gmail.com","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-05-20T20:17:22Z","receivedAt":"2008-05-20T20:17:22Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sverre Rabbelier wrote:\n> On Tue, May 20, 2008 at 9:44 PM, Shawn O. Pearce wrote:\n> > Junio defers almost all git-gui things to me, as I am the current\n> > maintainer of git-gui. You are right, it doesn't really hurt to\n> > include it, and now that it is written, the hard part is already\n> > done. I'll apply it to my main git-gui tree and ask Junio to\n> > include it in a future version of Git.\n> \n> Hmmm, maybe you should include in big red letters that the output from\n> --trace in no way or form represents commands that a user should use\n> daily?\n\nYea, probably.\n\n> I can hear the questions on #git already \"I don't understand,\n> I've used git-gui for months now, but the command it tells me to use\n> make no sense!\".\n\nYup. Or even worse, a user thinking that the best way to create a\nnew commit on the command line is the ugly sequence of:\n\n\tgit-write-tree\n\tgit-commit-tree ... -p ... Even better of course would be to not only print the plumbing commands\n> but also the porcelain commands!\n\nThat is probably difficult. Some of the code internally is more\nabout stringing the right sequence of plumbing together than it\nis about a particular user action. I think it would take a bit of\nwork to make it do this, and I just don't see a reason to do it.\n\nCVS clients that show CVS commands can easily do so, because they\nare directly executing the commands they show you. This is likely\nalso true of SVN commands. But git-gui on Git, that's a whole\ndifferent animal.\n\n-- \nShawn.\n"},{"id":"77340","messageId":"bd6139dc0805201322r6c8dae8cy45d31af6c25fd25a@mail.gmail.com","threadId":"13565","inReplyTo":"20080520201722.GF29038@spearce.org","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-05-20T20:22:35Z","receivedAt":"2008-05-20T20:22:35Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Tue, May 20, 2008 at 10:17 PM, Shawn O. Pearce wrote:\n> Yup. Or even worse, a user thinking that the best way to create a\n> new commit on the command line is the ugly sequence of:\n>\n> git-write-tree\n> git-commit-tree ... -p ... git-update-ref HEAD ...\n>\n\nThat would be awesome, no wait.. it wouldn't :P.\n\n>> Even better of course would be to not only print the plumbing commands\n>> but also the porcelain commands!\n>\n> That is probably difficult. Some of the code internally is more\n> about stringing the right sequence of plumbing together than it\n> is about a particular user action. I think it would take a bit of\n> work to make it do this, and I just don't see a reason to do it.\n\nThe reason would be to make the switch from using git-gui only to\nusing the commandline too... the again, it'd be cutting your own hand\n(or is it \"throat\" in English...) to make that transition easier.\n\n> CVS clients that show CVS commands can easily do so, because they\n> are directly executing the commands they show you. This is likely\n> also true of SVN commands. But git-gui on Git, that's a whole\n> different animal.\n\nAh, I didn't realise git-gui does stuff that you can't really do\nthrough the regular porcelain. In that case it would indeed be\nimpossible to print the regular porcelain commands. I think the\n'--trace' option should be advertised as 'debugging option' so that\nthe user can see what is going on in the case something goes wrong\nperhaps?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"77342","messageId":"20080520203153.GH29038@spearce.org","threadId":"13565","inReplyTo":"bd6139dc0805201322r6c8dae8cy45d31af6c25fd25a@mail.gmail.com","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-05-20T20:31:53Z","receivedAt":"2008-05-20T20:31:53Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sverre Rabbelier wrote:\n> >\n> > That is probably difficult. Some of the code internally is more\n> > about stringing the right sequence of plumbing together than it\n> > is about a particular user action. I think it would take a bit of\n> > work to make it do this, and I just don't see a reason to do it.\n> \n> The reason would be to make the switch from using git-gui only to\n> using the commandline too... the again, it'd be cutting your own hand\n> (or is it \"throat\" in English...) to make that transition easier.\n\nI'm not worried about users leaving git-gui. Hell, if git-gui\nwas just git on training wheels and all git users left git-gui\nafter a while for the command line that would be telling as it\nsays the graphical interface is not desired. Or that git-gui's\ninterface is not well suited to the task.\n\nFar from it. Some users like git-gui for its ability to show\nthe modified files, and let you stage/unstage individual hunks.\nOthers like its ability to perform checkout+pull in one mouse\nclick. Many like to point at things with a rodent than to use\nthe keyboard and enter (to them) isoteric commands.\n\nRight now there are really only two git GUIs; git-gui and QGit.\nEach has its strengths. Maybe this time next year we will have\na 3rd; name yet to be determined but it would come out of the\negit/jgit project as a stand-alone SWT/Java based Git UI.\n \n> > CVS clients that show CVS commands can easily do so, because they\n> > are directly executing the commands they show you. This is likely\n> > also true of SVN commands. But git-gui on Git, that's a whole\n> > different animal.\n> \n> Ah, I didn't realise git-gui does stuff that you can't really do\n> through the regular porcelain. In that case it would indeed be\n> impossible to print the regular porcelain commands. I think the\n> '--trace' option should be advertised as 'debugging option' so that\n> the user can see what is going on in the case something goes wrong\n> perhaps?\n\nYes. I'll send Junio a patch for Documentation/git-gui.txt and\ndescribe it as a debugging option, and also mention that the commands\nit displays aren't all meant to be invoked by mortals.\n\n-- \nShawn.\n"},{"id":"77344","messageId":"bd6139dc0805201346g411c7d64i16d206953e595b38@mail.gmail.com","threadId":"13565","inReplyTo":"20080520203153.GH29038@spearce.org","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Sverre Rabbelier","fromEmail":"alturin@gmail.com","sentAt":"2008-05-20T20:46:01Z","receivedAt":"2008-05-20T20:46:01Z","isPatch":false,"sender":{"key":"alturin@gmail.com","avatar":null},"body":"On Tue, May 20, 2008 at 10:31 PM, Shawn O. Pearce wrote:\n> Far from it. Some users like git-gui for its ability to show\n> the modified files, and let you stage/unstage individual hunks.\n> Others like its ability to perform checkout+pull in one mouse\n> click. Many like to point at things with a rodent than to use\n> the keyboard and enter (to them) isoteric commands.\n\nHeh, I've never understood that, but I have a classmate that won't\ntouch anything that doesn't have a \"shiney\" GUI that he likes (that\nis, he'll prefer the program with a \"shiney\" GUI even if there is one\nwithout that has better features).\n\n> Right now there are really only two git GUIs; git-gui and QGit.\n> Each has its strengths. Maybe this time next year we will have\n> a 3rd; name yet to be determined but it would come out of the\n> egit/jgit project as a stand-alone SWT/Java based Git UI.\n\nIs it \"shiney\"? If you haven't already, look into applying a theme to\nthe app, the Substance LAF definitely looks \"shiney\"!\n\n> Yes. I'll send Junio a patch for Documentation/git-gui.txt and\n> describe it as a debugging option, and also mention that the commands\n> it displays aren't all meant to be invoked by mortals.\n\nSounds like a plan (maybe use \"mere mortals\" instead ;), it's more cool).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"77347","messageId":"7v3aoc8xtg.fsf@gitster.siamese.dyndns.org","threadId":"13565","inReplyTo":"20080520203153.GH29038@spearce.org","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-20T21:34:03Z","receivedAt":"2008-05-20T21:34:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> Sverre Rabbelier wrote:\n>> >\n>> > That is probably difficult. Some of the code internally is more\n>> > about stringing the right sequence of plumbing together than it\n>> > is about a particular user action. I think it would take a bit of\n>> > work to make it do this, and I just don't see a reason to do it.\n>> \n>> The reason would be to make the switch from using git-gui only to\n>> using the commandline too... the again, it'd be cutting your own hand\n>> (or is it \"throat\" in English...) to make that transition easier.\n>\n> I'm not worried about users leaving git-gui. Hell, if git-gui\n> was just git on training wheels and all git users left git-gui\n> after a while for the command line that would be telling as it\n> says the graphical interface is not desired. Or that git-gui's\n> interface is not well suited to the task.\n>\n> Far from it. Some users like git-gui for its ability to show\n> the modified files, and let you stage/unstage individual hunks.\n> Others like its ability to perform checkout+pull in one mouse\n> click. Many like to point at things with a rodent than to use\n> the keyboard and enter (to them) isoteric commands.\n>\n> Right now there are really only two git GUIs; git-gui and QGit.\n> Each has its strengths. Maybe this time next year we will have\n> a 3rd; name yet to be determined but it would come out of the\n> egit/jgit project as a stand-alone SWT/Java based Git UI.\n> \n>> > CVS clients that show CVS commands can easily do so, because they\n>> > are directly executing the commands they show you. This is likely\n>> > also true of SVN commands. But git-gui on Git, that's a whole\n>> > different animal.\n>> \n>> Ah, I didn't realise git-gui does stuff that you can't really do\n>> through the regular porcelain. In that case it would indeed be\n>> impossible to print the regular porcelain commands. I think the\n>> '--trace' option should be advertised as 'debugging option' so that\n>> the user can see what is going on in the case something goes wrong\n>> perhaps?\n>\n> Yes. I'll send Junio a patch for Documentation/git-gui.txt and\n> describe it as a debugging option, and also mention that the commands\n> it displays aren't all meant to be invoked by mortals.\n\nProbably --trace should be renamed to --debug then?\n"},{"id":"77361","messageId":"20080521024126.GI29038@spearce.org","threadId":"13565","inReplyTo":"7v3aoc8xtg.fsf@gitster.siamese.dyndns.org","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-05-21T02:41:26Z","receivedAt":"2008-05-21T02:41:26Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> > Sverre Rabbelier wrote:\n> >> \n> >> Ah, I didn't realise git-gui does stuff that you can't really do\n> >> through the regular porcelain. In that case it would indeed be\n> >> impossible to print the regular porcelain commands. I think the\n> >> '--trace' option should be advertised as 'debugging option' so that\n> >> the user can see what is going on in the case something goes wrong\n> >> perhaps?\n> \n> Probably --trace should be renamed to --debug then?\n\nWell, we do have GIT_TRACE, and git-gui --trace is sort of the\nsame idea. :-)\n\nI was going to call it --debug, but went with --trace as it is\ncloser to GIT_TRACE than it is to say git-describe --debug.\n\n-- \nShawn.\n"},{"id":"77378","messageId":"alpine.DEB.1.00.0805210930150.30431@racer","threadId":"13565","inReplyTo":"20080521024126.GI29038@spearce.org","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-05-21T08:30:39Z","receivedAt":"2008-05-21T08:30:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 20 May 2008, Shawn O. Pearce wrote:\n\n> Junio C Hamano wrote:\n> > > Sverre Rabbelier wrote:\n> > >> \n> > >> Ah, I didn't realise git-gui does stuff that you can't really do\n> > >> through the regular porcelain. In that case it would indeed be\n> > >> impossible to print the regular porcelain commands. I think the\n> > >> '--trace' option should be advertised as 'debugging option' so that\n> > >> the user can see what is going on in the case something goes wrong\n> > >> perhaps?\n> > \n> > Probably --trace should be renamed to --debug then?\n> \n> Well, we do have GIT_TRACE, and git-gui --trace is sort of the\n> same idea. :-)\n\nWhich brings me to the suggestion to reuse GIT_TRACE instead of adding \nan option...\n\nCiao,\nDscho\n"},{"id":"77380","messageId":"20080521092700.GA28195@diana.vm.bytemark.co.uk","threadId":"13565","inReplyTo":"alpine.DEB.1.00.0805210930150.30431@racer","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-05-21T09:27:00Z","receivedAt":"2008-05-21T09:27:00Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-05-21 09:30:39 +0100, Johannes Schindelin wrote:\n\n> On Tue, 20 May 2008, Shawn O. Pearce wrote:\n>\n> > Junio C Hamano wrote:\n> >\n> > > Probably --trace should be renamed to --debug then?\n> >\n> > Well, we do have GIT_TRACE, and git-gui --trace is sort of the\n> > same idea. :-)\n>\n> Which brings me to the suggestion to reuse GIT_TRACE instead of\n> adding an option...\n\nFWIW, StGit uses STGIT_SUBPROCESS_LOG for this purpose. (Can be set to\n\"debug\" to get maximum details, or \"profile\" to get the time of each\nsubprocess call.)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"77459","messageId":"20080522121211.GL29038@spearce.org","threadId":"13565","inReplyTo":"alpine.DEB.1.00.0805210930150.30431@racer","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-05-22T12:12:11Z","receivedAt":"2008-05-22T12:12:11Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> On Tue, 20 May 2008, Shawn O. Pearce wrote:\n> > \n> > Well, we do have GIT_TRACE, and git-gui --trace is sort of the\n> > same idea. :-)\n> \n> Which brings me to the suggestion to reuse GIT_TRACE instead of adding \n> an option...\n\nWell... you may not want to see what GIT_TRACE causes, but you\ndo want to see what `git gui --trace` gives you. So I didn't\nwant to overload it.\n\n-- \nShawn.\n"},{"id":"77495","messageId":"320075ff0805221355y6d5dd4dcgdd12fad9582ea588@mail.gmail.com","threadId":"13565","inReplyTo":"20080520203153.GH29038@spearce.org","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Nigel Magnay","fromEmail":"nigel.magnay@gmail.com","sentAt":"2008-05-22T20:55:57Z","receivedAt":"2008-05-22T20:55:57Z","isPatch":false,"sender":{"key":"nigel.magnay@gmail.com","avatar":"https://gravatar.com/avatar/d85cf38287bef3a8e4fa02358d2756d7589f8676c5eeb881ce2f6d731e4526c3?d=mp&s=160"},"body":"> I'm not worried about users leaving git-gui. Hell, if git-gui\n> was just git on training wheels and all git users left git-gui\n> after a while for the command line that would be telling as it\n> says the graphical interface is not desired. Or that git-gui's\n> interface is not well suited to the task.\n>\n> Far from it. Some users like git-gui for its ability to show\n> the modified files, and let you stage/unstage individual hunks.\n> Others like its ability to perform checkout+pull in one mouse\n> click. Many like to point at things with a rodent than to use\n> the keyboard and enter (to them) isoteric commands.\n>\n> Right now there are really only two git GUIs; git-gui and QGit.\n> Each has its strengths. Maybe this time next year we will have\n> a 3rd; name yet to be determined but it would come out of the\n> egit/jgit project as a stand-alone SWT/Java based Git UI.\n>\n\nI have to say - git is the first SCM that I've used that commandline\nusage is actually pleasant in - so much so, the lack of easy cut&paste\nfrom 'git status' in colleagues cygwin windows becomes a serious pain!\n\ngit-gui is good though - but there's a few things I wish it had. I\noften find the need to flip between git gui and gitk (for a 'where the\nheck am I at the moment' overview) - the 2 tools seems to confuse\npeople coming at git, even given 'visualize branch'. It'd be nice to\nbe able to add files / directories to .gitignore, and to view the\nstaged/unstaged changes as trees - helpful for when a build has\ncreated a non-ignored directory with thousands of files. Maybe I\nshould get qgit - but git gui has the massive advantage of being in\nevery install by default, and so is available in msysgit.\n\nWhilst I'm thinking about it - I'm surprised in retrospect how little\nprominence the index is given in the frontends I've seen. It's easy,\ncoming from SVN, to gloss over the index as the same as just checking\noff files at commit time, and miss stuff like 'git add --patch' and\n'git mergetool' altogether.\n"},{"id":"77510","messageId":"20080522230545.GR29038@spearce.org","threadId":"13565","inReplyTo":"320075ff0805221355y6d5dd4dcgdd12fad9582ea588@mail.gmail.com","subject":"Re: git gui: Possible to see which commands are executed?","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-05-22T23:05:45Z","receivedAt":"2008-05-22T23:05:45Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nigel Magnay wrote:\n> \n> git-gui is good though - but there's a few things I wish it had. I\n> often find the need to flip between git gui and gitk (for a 'where the\n> heck am I at the moment' overview) - the 2 tools seems to confuse\n> people coming at git, even given 'visualize branch'.\n\nYup. I haven't tried to reimplement a visualizer in git-gui, nor\nhave I tried to embed gitk into git-gui. Both would take a great\ndeal of work I think (though embedding gitk is likely easier) and I\njust have too many things going on to pursue this myself. If someone\nshowed patches for this, I'd definately try to get them included.\n\n> It'd be nice to\n> be able to add files / directories to .gitignore,\n\nAlways been a \"wishlist\" feature for git-gui. Paul Mackerras' gitool\nprototype (which is what seeded git-gui) had this feature, but it was\nnever carried into git-gui. Again, patches welcome. :-)\n\n> and to view the\n> staged/unstaged changes as trees - helpful for when a build has\n> created a non-ignored directory with thousands of files.\n\nYea. And when that happens to me I immediately slap the directory\ninto my .gitignore or .git/info/exclude and rescan to make the huge\npile of untracked files disappear. So a tree view in git-gui has\nnever been something I wanted. Trees in Tcl/Tk are also horrible\nto implement. The toolkit just has never been very good at that\nsort of thing.\n\n> Maybe I\n> should get qgit - but git gui has the massive advantage of being in\n> every install by default, and so is available in msysgit.\n\nYes, I have to admit that git-gui's popularity among git users has a\n_lot_ to do with the simple fact that it ships out of the box as part\nof Junio's git releases. Since most git users have Tcl/Tk available\nso they can use gitk, git-gui is also ready-to-go, with no extra libs\nneeded on your system.\n\nHowever, QGit is also a good program, and has many loyal users.\nThere are benefits and drawbacks to both GUIs.\n \n> Whilst I'm thinking about it - I'm surprised in retrospect how little\n> prominence the index is given in the frontends I've seen.\n\nReally? git-gui is all about the index.\n\n> It's easy,\n> coming from SVN, to gloss over the index as the same as just checking\n> off files at commit time, and miss stuff like 'git add --patch' and\n> 'git mergetool' altogether.\n\nRight click on a hunk in the diff pane in git-gui and stage/unstage\nit? Its about as good as `git add --patch`. Or better, depending\non how you work.\n\n-- \nShawn.\n"}]}