Barebone Porcelain. Where to stop?

Barebone Porcelain. Where to stop?

[Junio C Hamano]

I have been somewhat disturbed and confused by the fact that the
line between what Porcelain like Cogito does and what we ship as
part of "core GIT" is getting more and more blurred.  This was
especially so while I was working on the $GIT_DIR/branches/
patch.

This trend started when "git diff", "git commit" and friends
were added for the sake of usability of the bare Plumbing.
These basic commands are must and I do not have any objection to
have them in the "core GIT" suite, but at the same time I think
the core should not be competing with Porcelains, and feel that
a line should be drawn somewhere [*1*].

I'd like to hear opinions from the list.  Personally I think
what we have so far is about right, relative to what the current
crop of Porcelains offer.

This is me speaking as just "an individual developer".  Linus as
"the project lead", Pasky as the maintainer of the de-facto
standard Porcelain, and others on the list may have different
opinions.  I do not think the core GIT should be making drastic
innovations that Porcelain folks have not asked.  In my ideal
world, Porcelains would be the first to innovate in the UI and
use pattern area, and while doing so, would discover something
lacking from the core.  The purpose of the core GIT development
should primarily be to fill these needs.  Then, once "best
current practices" from Porcelains emerge, the infrastructure to
support them would become a part of core GIT; we might even
start shipping corresponding barebone Porcelain scripts to
codify that BCP using the same support infrastructure as part of
the "core GIT" suite [*2*].

Linus said that the current Plumbing already does all he wants
it to do.  I started sharing the same opinion.  I am finding
myself using my own Porcelain commands less frequently for doing
basic things, because the barebone Porcelain already fills much
of my needs.


[Footnotes]

*1* Yes, I publicly stated that one of my goals of my
involvement in GIT development was to make choice of Porcelain
more or less irrelevant, and that still stands, which means that
I am in favor of having rich enough barebone Porcelain shipped
with "core GIT".  But the problem I am having is now is how rich
is rich enough.

*2* ... and that is how we make the Porcelain less relevant ;-).

Re: Barebone Porcelain. Where to stop?

[Bryan Larsen]

Junio C Hamano wrote:
> I have been somewhat disturbed and confused by the fact that the
> line between what Porcelain like Cogito does and what we ship as
> part of "core GIT" is getting more and more blurred.  This was
> especially so while I was working on the $GIT_DIR/branches/
> patch.

I have also been disturbed.  But I am gratified that such a core git 
personage shares my concern.   This is enough from a technical point of 
view, at least for me.

Any lack of porcelain momentum is probably due to git having better 
documentation than the current porcelains, such as cogito and stacked 
git.  The documentation, like tutorial.txt and Jeff Garzik's git kernel 
howto give the impression that most kernel folks use git instead of cogito.

I personally think that the cogito interface and stacked git interfaces 
are much nicer than git's, and would like to see these two tools achieve 
some momentum.

Another way of encouraging porcelain is by helping Pasky and Catalin 
out.  Myself, I have been sending corresponding patches for Cogito  and 
Stacked when making changes to git.  This is purely selfish: I use both 
of these porcelains, but if it became general practice, we'd probably 
see less breakage.

Bryan

Re: Barebone Porcelain. Where to stop?

[Catalin Marinas]

Bryan Larsen <bryan.larsen@gmail.com> wrote:
> Any lack of porcelain momentum is probably due to git having better
> documentation than the current porcelains, such as cogito and stacked
> git.  The documentation, like tutorial.txt and Jeff Garzik's git
> kernel howto give the impression that most kernel folks use git
> instead of cogito.
>
> I personally think that the cogito interface and stacked git
> interfaces are much nicer than git's, and would like to see these two
> tools achieve some momentum.

I don't see git going towards stgit at all. Indeed, it gets closer to
cogito but I still like cogito over plain git since it's easier to use
(my goal, though, is to add pull/clone commands to stgit so that one
doesn't need to rely on directly using other tools).

I am aware that, probably, the biggest problem with stgit is the
documentation (and also a lack of regression tests). I hope I will
find some time soon to write a tutorial and improve the command line
help. I will setup a wiki in the next few days so that others can
easily fix/update the documentation.

-- 
Catalin

Re: Barebone Porcelain. Where to stop?

[Junio C Hamano]

Catalin Marinas <catalin.marinas@gmail.com> writes:

> I don't see git going towards stgit at all. Indeed, it gets closer to
> cogito but I still like cogito over plain git since it's easier to use
> (my goal, though, is to add pull/clone commands to stgit so that one
> doesn't need to rely on directly using other tools).

All good to hear.  I do not speak for Linus, but I think core
should not be competing with Porcelain.  To me, there are four
purposes for the barebone Porcelain layer:

 (1) provide the end user a minimum UI to do essential things.

 (2) codify the BCP/convention to use the core by higher level
     SCMs to help them stay compatible with each other where
     possible (e.g. "what .git/HEAD means, when it gets updated,
     and to what" was discussed recently).

 (3) serve as an example for people interested in learning the
     core GIT (i.e. they may be starting their own Porcelain).

 (4) implement operations that are heavy on logic/convention but
     does not have much UI need so that higher level SCMs can
     implement their own UI by just being a thin wrapper around
     them (e.g. clone/fetch and push).

> I am aware that, probably, the biggest problem with stgit is the
> documentation (and also a lack of regression tests). I hope I will
> find some time soon to write a tutorial and improve the command line
> help. I will setup a wiki in the next few days so that others can
> easily fix/update the documentation.

Wonderful.

Re: Barebone Porcelain. Where to stop?

[Frank Sorenson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Junio C Hamano wrote:
> Catalin Marinas <catalin.marinas@gmail.com> writes:
> 
>>I don't see git going towards stgit at all. Indeed, it gets closer to
>>cogito but I still like cogito over plain git since it's easier to use
>>(my goal, though, is to add pull/clone commands to stgit so that one
>>doesn't need to rely on directly using other tools).
> 
> All good to hear.  I do not speak for Linus, but I think core
> should not be competing with Porcelain.  To me, there are four
> purposes for the barebone Porcelain layer:
> 
>  (1) provide the end user a minimum UI to do essential things.
> 
>  (2) codify the BCP/convention to use the core by higher level
>      SCMs to help them stay compatible with each other where
>      possible (e.g. "what .git/HEAD means, when it gets updated,
>      and to what" was discussed recently).
> 
>  (3) serve as an example for people interested in learning the
>      core GIT (i.e. they may be starting their own Porcelain).
> 
>  (4) implement operations that are heavy on logic/convention but
>      does not have much UI need so that higher level SCMs can
>      implement their own UI by just being a thin wrapper around
>      them (e.g. clone/fetch and push).

These all sound good.  Along the lines of #4, one potential purpose I've
been curious about is the possibility of pulling these core operations
out into a library that Porcelain could use directly.  This way,
Porcelain, including the minimum git UI (your #1), could directly link
in and call the needed functions, and rather than stringing sequences of
git-whatever commands together in a shell script.

This would allow Porcelain to take advantage of the core git more
directly, and would improve the speed of Porcelain.  The minimum UI (#1)
would be a much simpler example (#3), since it would only be the
front-end, rather than the front-end/back-end combination it is now.

Is this something we want to consider, or am I out in left field? :)

Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC3BfFaI0dwg4A47wRApyQAKD3yXqYfcm7TgJ5GnIZsw5ZcB+P/wCgpM75
cjPHXi8jd0VthQjKNFITFxU=
=Jxx/
-----END PGP SIGNATURE-----

Re: Barebone Porcelain. Where to stop?

[Junio C Hamano]

Frank Sorenson <frank@tuxrocks.com> writes:

> Is this something we want to consider, or am I out in left field? :)

I do not think so.  You just more clearly and explicitly stated
what I wanted to see; we share the same vision of the ideal
world.

I do however think your sights are probably focused at somewhere
a lot further then mine ;-).  C level interfaces to those
aggregated common operations would happen once after we identify
what kind of common operations are useful to have, prototyping
them (most likely in scripting environment), and if it turns out
to be useful and performance critical.  I personally do not
think we are there yet.