Re: git gui: Possible to see which commands are executed?
"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 43 quoted lines
> 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?