On Oct 20, 2007, at 10:03 AM, Andreas Ericsson wrote:

quoted text
>
> 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-<tab>
> 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.

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.

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.

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.

admin: Some commands are not used in a typical workflow. For
   example git-filter-branch or git-fsck have a more admin
   flavor.

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.

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.

	Steffen

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html