Barebone Porcelain. Where to stop?

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 ;-).

Junio C Hamano wrote:

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

Bryan Larsen <bryan.larsen@gmail.com> wrote:

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 Marinas <catalin.marinas@gmail.com> writes:

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).

Wonderful.

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

Junio C Hamano wrote:

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

Frank Sorenson <frank@tuxrocks.com> writes:

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.