From: Andreas Ericsson Date: Sat, 20 Oct 2007 11:29:31 GMT Subject: Re: Git User's Survey 2007 unfinished summary continued Message-ID: <4719E69B.3020906@op5.se> In-Reply-To: Steffen Prohaska wrote: > > On Oct 20, 2007, at 10:03 AM, Andreas Ericsson wrote: > >> >> Personally, I can't help but think that the numerous times I've heard "oh >> gods, that's a lot of commands" should finally mean something. I've >> started >> taking a look at which of them one can bundle together. If we can drop >> the >> porcelainish commands down to ~30 or so, and hide the plumbing from >> git- >> listings, the initial hurdle people have to jump would be >> significantly lower. > > Maybe we could group commands into more categories? > > plumbing: should be hidden from the 'normal' user. Porcelain > should be sufficient for every standard task. > Agreed. /usr/libexec/git/ seems to me to be the ideal spot for it. > core porcelain: this is what everyone needs who works in a > pure git based workflow based on push/pull. You can't use > git without these commands. But these commands are already > sufficient to solve most of your tasks. > Agreed. > mail porcelain: the list will probably hate me for this, but > I think all commands needed to create and send patches per > mail are not essential. I suspect that I'll _never_ ask > my colleagues at work to send me a patch by mail. They'll > always push it to a shared repo. > Disagreed, for obvious reasons. Many OSS projects are patch-centric and developed much like git. OTOH, having to run "git format-patch" rather than "git-format-patch" probably isn't so hampering that we can't live with it. > import/export: Many commands are only used for importing > from or exporting to other version control systems. Examples > are git-cvs*, git-svn*. They are not needed once you switched > to git. > But very nifty for incremental imports. I track several CVS repos that I continuously import. They're also self-explanatory, so they don't add much to the clutter. Same reasons as above though; there's no real reason not to invoke them as "git cvsimport" rather than "git-cvsimport". > admin: Some commands are not used in a typical workflow. For > example git-filter-branch or git-fsck have a more admin > flavor. > git-filter-branch could definitely live its life hidden somewhere. git-fsck probably should stay with the plumbing, as it's used by other porcelainish programs more often than run directly by the user. > There might be more categories. I am not sure because there > a quite a few commands that I _never_ used and have no clear > idea about what they do. > > > So here are a few questions: > > Could we find a small set of core porcelain commands that > completely cover a typical workflow? The core section of the > manual should only refer to those commands. Absolutely no > plumbing should be needed to tweak things. In principle, a > typical user should be able to work if _all other_ commands > except for core porcelain are hidden from his PATH. > Note that this is already possible, using a libexec-dir and passing --exec-dir to the git wrapper. The only thing that isn't done is deciding what's *definitely* plumbing. Once that's defined, the makefile can install plumbing to a separate directory and the /usr/bin/git- should shrink by roughly half. > Another section in the manual should describe a workflow based > on sending patches around. Obviously the mail porcelain is > needed for this. > > ... and so forth. > > I don't know if we really want to hide the commands from PATH. > But maybe we should consider grouping them into subdirectories, > or provide another way to for the user to focus on the core > porcelain. > Hiding the really core plumbing and getting rid of redundant programs (git-am, git-apply, git-applypatch, ...) would do wonders, methinks. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231