Steffen Prohaska wrote:
quoted text
> 
> 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-<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.
> 

Agreed. /usr/libexec/git/ seems to me to be the ideal spot for
it.

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

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

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

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

quoted text
> 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-<tab> should shrink by roughly half.

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