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-<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.
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-<tab> 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@xxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
