Petr Baudis <pasky@xxxxxxx> writes: > On Wed, Nov 15, 2006 at 01:31:50AM CET, Junio C Hamano wrote: >> >> I am of two minds here. >> >> I do not think the Porcelain-ish UI that is shipped with git >> should be taken with the same degree of "authority" as git >> Plumbing. > ..snip passage about workflows.. > > Controversy's fun, so... > > <Cogito maintainer hat _off_> (But yeah, it still looks silly that I'm > saying this.) It appears that you are not grumpy as you were anymore ;-). I mostly agree with what you said in your message. > (i) Clearly divided porcelain/plumbing interface, so that you can > really isolate the two UI-wise; endless confusion reigns there now. Is > git-update-index porcelain or plumbing? _You_ call git-merge a proper > porcelain? From my perspective, git-update-ref is as plumbing as it > gets, but it's classified as porcelain. Etc, etc. This would be by far > the most important advantage. Yes. The current "merge" started its life as Linus's porcelain (we did not have fetch and pull infrastructure back then) but quickly has become just a helper for pull to produce a merge commit. If anybody thinks its UI is good as a general end-user level command, there is a need for "head examination". As you say, update-ref is as plumbing as it gets and it should not be listed as Porcelain; I am a bit surprised that it is labelled as such myself. No disagreement here, nor (ii) nor (iii). > (ii) The plumbing and porcelain would not share the same namespace, > leading to clearer UI. (I'm just inflating (i).) > > (iii) The documentation would not be a strange mix of porcelain and > plumbing. (More (i) inflation.) > > (iv) (i) is troublesome because I have a feeling that Junio declared > several times that he doesn't care that much about stable API for > porcelain compared to the plumbing. But with the current mix it's > desirable to use some porcelain even in other porcelains and in scripts. This is true and it is a problem. While we encourage Porcelain writers to use plumbing in order to give git Porcelain-ish more freedom to evolve to give better UI for humans, not having a clear distinction between the two makes it harder. > (v) Git would be properly libified by now. If you wanted to convert > bits of porcelain to C, it would be at least much higher priority. I am not sure about "libified" part and I do not know what bits of porcelain wants to become C right now. But I do not think this point is important part of your list. > (vi) You wouldn't need to make the gruesome choice on what is the > canonical workflow the _the_ Git porcelain supports (see the snipped > passage). Or you would, but it would have less impact. Yes. This is really important. Linus and me having done Porcelain-ish that supports integrator role workflow better than other workflows such as contributor role should not discourage people from working on alternative or complementary Porcelains to help other workflows better (see the snipped passage). StGIT sets a great example, and efforts like it is encoraged more. I think both Linus and myself tried to make it clear that the purpose of Porcelain-ish that comes with core git is 50% to make plumbing (perhaps minimally) usable and the other 50% to serve as an example for Porcelain writers to learn how to use the plumbing, but we should probably have stressed the latter better. - 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