Andy Parkins [off-list ref] writes:
On Wednesday 2006, November 15 18:16, Junio C Hamano wrote:
quoted
I still think in the long run you would be better off giving
separate names to Porcelains because I am sure you are going to
The problem I think with that is that the line between plumbing and porcelain
is not clear.
This is moot because we (at least tentatively) agreed not to do
"gh" or "ig" or whatever, but I do not understand why you feel
so.
If we had a separate Porcelain namespace (say "ng" for "new
git") you would know "ng-commit" is not a Plumbing and when you
are writing a Porcelain script you would stay away from using it
in your script.
In the longer term, when the new Porcelain UI Nico and friends
are designing matures, and if it makes everybody (including
existing users who learned git-* Porcelain-ish during 18-months
process) happy, we could gradually deprecate and eventually
remove the git-* Porcelain-ish over time, at that point we would
have a very clear line between plumbing and porcelain.
But that would not be a flag-day change. During the transition
period you cannot mechanically tell if git-foo is a plumbing or
a porcelain just like you cannot do so now.
On Wed, 15 Nov 2006, Junio C Hamano wrote:
If we had a separate Porcelain namespace (say "ng" for "new
git") you would know "ng-commit" is not a Plumbing and when you
are writing a Porcelain script you would stay away from using it
in your script.
There is merit in trying to segregate porcelain vs plumbing... at least
in theory. In practice though I don't think this is something we should
absolutely strive for.
Why? Because something is always going to fail the categorization.
Sure there are commands that are pure plumbing like git-commit-tree,
etc. Some are pure porcelain like git-commit or git-log. Yet we use
git-log's output for git-shortlog. Does it mean that git-log is
plumbing? Also I have a script here that uses git-commit directly
because it is so much convenient rather than futzing with the really
bare plumbing. I don't think git-commit should be prevented from being
used within another script even if it is classified as porcelain.
So we have that notion of plumbing vs porcelain but in practice there is
a whole spectrum between those two poles and I think it is a good thing.
On Wed, 15 Nov 2006 11:41:20 -0800, Junio C Hamano wrote:
Andy Parkins [off-list ref] writes:
quoted
On Wednesday 2006, November 15 18:16, Junio C Hamano wrote:
quoted
I still think in the long run you would be better off giving
separate names to Porcelains because I am sure you are going to
The problem I think with that is that the line between plumbing and porcelain
is not clear.
This is moot because we (at least tentatively) agreed not to do
"gh" or "ig" or whatever, but I do not understand why you feel
so.
I'm not the original poster, but I feel the same way about the line
being unclear.
Here's a real-world example from last week.
For cairo I wrote a little script that two revspecs, (or one in
which case its first parent is used), and it goes off and checks out
both versions, builds each, runs a performance test on each, and then
generates a report showing the performance impact.
So now I can do things like:
# What's the performance impact of my latest change:
cairo-perf-diff HEAD
# Have my last few changes helped as much as I'd hoped:
cairo-perf-diff HEAD~3 HEAD
# How has performance changed since our last stable release:
cairo-perf-diff 1.2.6 HEAD
Anyway, when I announced this I also mentioned how easily someone
might generate an entire series of reports for a series of
commits. The command I gave as an example is:
for rev in $(git rev-list 1.2.6..HEAD); do
cairo-perf-diff $rev
done
I think that's a perfectly legitimate one-liner for users to use, and
it really shows off the easy-scriptability of git. But certainly, no
"new porcelain" author is going to consider rev-list to be porcelain
rather than plumbing, right? So as soon as I start teaching people to
do useful stuff like this, they might have to reach down into the
"scary" git interface.
I think we're much better off just having one "git" namespace for the
standard command-line interface, and then making it as easy to use as
possible.
-Carl