Sverre Rabbelier <alturin@xxxxxxxxx> wrote:
> On Tue, May 20, 2008 at 9:44 PM, Shawn O. Pearce <spearce@xxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
