El 1/12/2007, a las 0:10, Johannes Schindelin escribió:
To me, it is mighty annoying anybody brings up that "144 commands"
argument Linus was referring to, and if there is _any_ way to shut up
those bikeshedders, I am all for it.
This is not a bikeshed argument and it is not an "idiotic
complaint" (to use Linus' phrase). It is a legitimate concern and a
*real* UI problem.
You and Linus don't care that there are 140+ Git commands and I
imagine that you know exactly what each of them does.
I don't really care either because although I don't know what every
single command does, I know what the 20 or 30 commands I personally
need for my own workflow do.
The problem is for *newcomers* to Git who sit down for the first time
and ask themselves, "Now, how do I...?". This is not an idiotic
complaint but a legitimate concern about a real UI problem.
Honestly, Johannes, do you think the following is a good UI?
$ git
Display all 148 possibilities? (y or n)
git* git-cvsimport* git-local-
fetch* git-peek-remote* git-show-index*
git-add* git-cvsserver* git-
log* git-prune* git-show-ref*
git-add--interactive* git-daemon* git-lost-
found* git-prune-packed* git-ssh-fetch*
git-am* git-describe* git-ls-
files* git-pull* git-ssh-pull*
git-annotate* git-diff* git-ls-
remote* git-push* git-ssh-push*
git-apply* git-diff-files* git-ls-
tree* git-quiltimport* git-ssh-upload*
git-applymbox git-diff-index* git-
mailinfo* git-read-tree* git-stash*
git-applypatch git-diff-tree* git-
mailsplit* git-rebase* git-status*
git-archimport* git-fast-import* git-
merge* git-rebase--interactive* git-stripspace*
git-archive* git-fetch* git-merge-
base* git-receive-pack* git-submodule*
git-bisect* git-fetch--tool* git-merge-
file* git-reflog* git-svn*
git-blame* git-fetch-pack* git-merge-
index* git-relink* git-svnimport
git-branch* git-filter-branch* git-merge-
octopus* git-remote* git-symbolic-ref*
git-bundle* git-fmt-merge-msg* git-merge-one-
file* git-repack* git-tag*
git-cat-file* git-for-each-ref* git-merge-
ours* git-repo-config* git-tar-tree*
git-check-attr* git-format-patch* git-merge-
recursive* git-request-pull* git-unpack-file*
git-check-ref-format* git-fsck* git-merge-
resolve* git-rerere* git-unpack-objects*
git-checkout* git-fsck-objects* git-merge-
stupid* git-reset* git-update-index*
git-checkout-index* git-gc* git-merge-
subtree* git-rev-list* git-update-ref*
git-cherry* git-get-tar-commit-id* git-merge-
tree* git-rev-parse* git-update-server-info*
git-cherry-pick* git-grep* git-
mergetool* git-revert* git-upload-archive*
git-citool git-gui/ git-
mktag* git-rm* git-upload-pack*
git-clean* git-hash-object* git-
mktree* git-runstatus* git-var*
git-clone* git-http-fetch* git-
mv* git-send-email* git-verify-pack*
git-commit* git-http-push* git-name-
rev* git-send-pack* git-verify-tag*
git-commit-tree* git-imap-send* git-pack-
objects* git-sh-setup* git-whatchanged*
git-config* git-index-pack* git-pack-
redundant* git-shell* git-write-tree*
git-convert-objects git-init* git-pack-
refs* git-shortlog* gitk
git-count-objects* git-init-db* git-parse-
remote* git-show*
git-cvsexportcommit* git-instaweb* git-patch-
id* git-show-branch*
Would you argue that this screenshot shows a sane UI?
<http://wincent.com/tmp/git-ui.png>
Note: I am not complaining about the *number* of commands; I myself
find them highly useful for scripting. I am saying that the
*visibility* of those commands is the problem. That's why I support
the efforts to move most of this stuff out of the default PATH. We're
not talking about getting rid of it, just about putting it somewhere
more appropriate in order to correct what is basically a *hideous*
user interface for the beginner.
Cheers,
Wincent
-
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
