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

[Junio C Hamano <gitster@pobox.com>]

"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?