{"thread":{"id":"1258","subject":"Barebone Porcelain. Where to stop?","startedAt":"2005-07-16T17:37:45Z","lastAt":"2005-07-19T00:10:36Z","messageCount":6,"participants":["Junio C Hamano","Bryan Larsen","Catalin Marinas","Frank Sorenson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"6191","messageId":"7vek9yirdi.fsf@assigned-by-dhcp.cox.net","threadId":"1258","inReplyTo":null,"subject":"Barebone Porcelain. Where to stop?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-16T17:37:45Z","receivedAt":"2005-07-16T17:37:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I have been somewhat disturbed and confused by the fact that the\nline between what Porcelain like Cogito does and what we ship as\npart of \"core GIT\" is getting more and more blurred. This was\nespecially so while I was working on the $GIT_DIR/branches/\npatch.\n\nThis trend started when \"git diff\", \"git commit\" and friends\nwere added for the sake of usability of the bare Plumbing.\nThese basic commands are must and I do not have any objection to\nhave them in the \"core GIT\" suite, but at the same time I think\nthe core should not be competing with Porcelains, and feel that\na line should be drawn somewhere [*1*].\n\nI'd like to hear opinions from the list. Personally I think\nwhat we have so far is about right, relative to what the current\ncrop of Porcelains offer.\n\nThis is me speaking as just \"an individual developer\". Linus as\n\"the project lead\", Pasky as the maintainer of the de-facto\nstandard Porcelain, and others on the list may have different\nopinions. I do not think the core GIT should be making drastic\ninnovations that Porcelain folks have not asked. In my ideal\nworld, Porcelains would be the first to innovate in the UI and\nuse pattern area, and while doing so, would discover something\nlacking from the core. The purpose of the core GIT development\nshould primarily be to fill these needs. Then, once \"best\ncurrent practices\" from Porcelains emerge, the infrastructure to\nsupport them would become a part of core GIT; we might even\nstart shipping corresponding barebone Porcelain scripts to\ncodify that BCP using the same support infrastructure as part of\nthe \"core GIT\" suite [*2*].\n\nLinus said that the current Plumbing already does all he wants\nit to do. I started sharing the same opinion. I am finding\nmyself using my own Porcelain commands less frequently for doing\nbasic things, because the barebone Porcelain already fills much\nof my needs.\n\n\n[Footnotes]\n\n*1* Yes, I publicly stated that one of my goals of my\ninvolvement in GIT development was to make choice of Porcelain\nmore or less irrelevant, and that still stands, which means that\nI am in favor of having rich enough barebone Porcelain shipped\nwith \"core GIT\". But the problem I am having is now is how rich\nis rich enough.\n\n*2* ... and that is how we make the Porcelain less relevant ;-).\n"},{"id":"6238","messageId":"42DB32F1.5020900@gmail.com","threadId":"1258","inReplyTo":"7vek9yirdi.fsf@assigned-by-dhcp.cox.net","subject":"Re: Barebone Porcelain. Where to stop?","fromName":"Bryan Larsen","fromEmail":"bryan.larsen@gmail.com","sentAt":"2005-07-18T04:41:21Z","receivedAt":"2005-07-18T04:41:21Z","isPatch":false,"sender":{"key":"bryan@larsen.st","avatar":"https://avatars.githubusercontent.com/u/32073?v=4"},"body":"Junio C Hamano wrote:\n> I have been somewhat disturbed and confused by the fact that the\n> line between what Porcelain like Cogito does and what we ship as\n> part of \"core GIT\" is getting more and more blurred. This was\n> especially so while I was working on the $GIT_DIR/branches/\n> patch.\n\nI have also been disturbed. But I am gratified that such a core git \npersonage shares my concern. This is enough from a technical point of \nview, at least for me.\n\nAny lack of porcelain momentum is probably due to git having better \ndocumentation than the current porcelains, such as cogito and stacked \ngit. The documentation, like tutorial.txt and Jeff Garzik's git kernel \nhowto give the impression that most kernel folks use git instead of cogito.\n\nI personally think that the cogito interface and stacked git interfaces \nare much nicer than git's, and would like to see these two tools achieve \nsome momentum.\n\nAnother way of encouraging porcelain is by helping Pasky and Catalin \nout. Myself, I have been sending corresponding patches for Cogito and \nStacked when making changes to git. This is purely selfish: I use both \nof these porcelains, but if it became general practice, we'd probably \nsee less breakage.\n\nBryan\n"},{"id":"6247","messageId":"tnx3bqcxvkm.fsf@arm.com","threadId":"1258","inReplyTo":"42DB32F1.5020900@gmail.com","subject":"Re: Barebone Porcelain. Where to stop?","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-07-18T10:22:33Z","receivedAt":"2005-07-18T10:22:33Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Bryan Larsen wrote:\n> Any lack of porcelain momentum is probably due to git having better\n> documentation than the current porcelains, such as cogito and stacked\n> git. The documentation, like tutorial.txt and Jeff Garzik's git\n> kernel howto give the impression that most kernel folks use git\n> instead of cogito.\n>\n> I personally think that the cogito interface and stacked git\n> interfaces are much nicer than git's, and would like to see these two\n> tools achieve some momentum.\n\nI don't see git going towards stgit at all. Indeed, it gets closer to\ncogito but I still like cogito over plain git since it's easier to use\n(my goal, though, is to add pull/clone commands to stgit so that one\ndoesn't need to rely on directly using other tools).\n\nI am aware that, probably, the biggest problem with stgit is the\ndocumentation (and also a lack of regression tests). I hope I will\nfind some time soon to write a tutorial and improve the command line\nhelp. I will setup a wiki in the next few days so that others can\neasily fix/update the documentation.\n\n-- \nCatalin\n"},{"id":"6253","messageId":"7v8y04q6sj.fsf@assigned-by-dhcp.cox.net","threadId":"1258","inReplyTo":"tnx3bqcxvkm.fsf@arm.com","subject":"Re: Barebone Porcelain. Where to stop?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-18T18:59:40Z","receivedAt":"2005-07-18T18:59:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Catalin Marinas writes:\n\n> I don't see git going towards stgit at all. Indeed, it gets closer to\n> cogito but I still like cogito over plain git since it's easier to use\n> (my goal, though, is to add pull/clone commands to stgit so that one\n> doesn't need to rely on directly using other tools).\n\nAll good to hear. I do not speak for Linus, but I think core\nshould not be competing with Porcelain. To me, there are four\npurposes for the barebone Porcelain layer:\n\n (1) provide the end user a minimum UI to do essential things.\n\n (2) codify the BCP/convention to use the core by higher level\n SCMs to help them stay compatible with each other where\n possible (e.g. \"what .git/HEAD means, when it gets updated,\n and to what\" was discussed recently).\n\n (3) serve as an example for people interested in learning the\n core GIT (i.e. they may be starting their own Porcelain).\n\n (4) implement operations that are heavy on logic/convention but\n does not have much UI need so that higher level SCMs can\n implement their own UI by just being a thin wrapper around\n them (e.g. clone/fetch and push).\n\n> I am aware that, probably, the biggest problem with stgit is the\n> documentation (and also a lack of regression tests). I hope I will\n> find some time soon to write a tutorial and improve the command line\n> help. I will setup a wiki in the next few days so that others can\n> easily fix/update the documentation.\n\nWonderful.\n"},{"id":"6259","messageId":"42DC17C5.80000@tuxrocks.com","threadId":"1258","inReplyTo":"7v8y04q6sj.fsf@assigned-by-dhcp.cox.net","subject":"Re: Barebone Porcelain. Where to stop?","fromName":"Frank Sorenson","fromEmail":"frank@tuxrocks.com","sentAt":"2005-07-18T20:57:41Z","receivedAt":"2005-07-18T20:57:41Z","isPatch":false,"sender":{"key":"frank@tuxrocks.com","avatar":null},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nJunio C Hamano wrote:\n> Catalin Marinas writes:\n> \n>>I don't see git going towards stgit at all. Indeed, it gets closer to\n>>cogito but I still like cogito over plain git since it's easier to use\n>>(my goal, though, is to add pull/clone commands to stgit so that one\n>>doesn't need to rely on directly using other tools).\n> \n> All good to hear. I do not speak for Linus, but I think core\n> should not be competing with Porcelain. To me, there are four\n> purposes for the barebone Porcelain layer:\n> \n> (1) provide the end user a minimum UI to do essential things.\n> \n> (2) codify the BCP/convention to use the core by higher level\n> SCMs to help them stay compatible with each other where\n> possible (e.g. \"what .git/HEAD means, when it gets updated,\n> and to what\" was discussed recently).\n> \n> (3) serve as an example for people interested in learning the\n> core GIT (i.e. they may be starting their own Porcelain).\n> \n> (4) implement operations that are heavy on logic/convention but\n> does not have much UI need so that higher level SCMs can\n> implement their own UI by just being a thin wrapper around\n> them (e.g. clone/fetch and push).\n\nThese all sound good. Along the lines of #4, one potential purpose I've\nbeen curious about is the possibility of pulling these core operations\nout into a library that Porcelain could use directly. This way,\nPorcelain, including the minimum git UI (your #1), could directly link\nin and call the needed functions, and rather than stringing sequences of\ngit-whatever commands together in a shell script.\n\nThis would allow Porcelain to take advantage of the core git more\ndirectly, and would improve the speed of Porcelain. The minimum UI (#1)\nwould be a much simpler example (#3), since it would only be the\nfront-end, rather than the front-end/back-end combination it is now.\n\nIs this something we want to consider, or am I out in left field? :)\n\nFrank\n- --\nFrank Sorenson - KD7TZK\nSystems Manager, Computer Science Department\nBrigham Young University\nfrank@tuxrocks.com\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.2.6 (GNU/Linux)\nComment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org\n\niD8DBQFC3BfFaI0dwg4A47wRApyQAKD3yXqYfcm7TgJ5GnIZsw5ZcB+P/wCgpM75\ncjPHXi8jd0VthQjKNFITFxU=\n=Jxx/\n-----END PGP SIGNATURE-----\n"},{"id":"6261","messageId":"7vy883lkoz.fsf@assigned-by-dhcp.cox.net","threadId":"1258","inReplyTo":"42DC17C5.80000@tuxrocks.com","subject":"Re: Barebone Porcelain. Where to stop?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-19T00:10:36Z","receivedAt":"2005-07-19T00:10:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Frank Sorenson writes:\n\n> Is this something we want to consider, or am I out in left field? :)\n\nI do not think so. You just more clearly and explicitly stated\nwhat I wanted to see; we share the same vision of the ideal\nworld.\n\nI do however think your sights are probably focused at somewhere\na lot further then mine ;-). C level interfaces to those\naggregated common operations would happen once after we identify\nwhat kind of common operations are useful to have, prototyping\nthem (most likely in scripting environment), and if it turns out\nto be useful and performance critical. I personally do not\nthink we are there yet.\n"}]}