On Tue, 14 Nov 2006 18:55:51 +0000, Andy Whitcroft wrote:
> Carl Worth wrote:
> > As has been discussed recently, update-index isn't intended as a
> > "porcelain" command so the mention of it in the output of git-commit
> > does lead to some user confusion.
>
> Are we sure this isn't porcelain-ish? We need to use it in merge
> conflict correction and the like? You can't use git-commit there as a
> replacement. I'd expect it to be 'git update-index' rather than
> 'git-update-index' of course.
It was Junio that recently said update-index is plumbing, not
porcelain.
So, the fact that conflict resolution still requires the use of
update-index would just be the next thing to fix. A name for a
replacement to use there could be "git resolve <paths>", (since the
old git-resolve is now officially deprecated). That's a name that
matches what hg uses in this situation, (another option is "resolved"
which is what stg uses, but I think verbs for commands work better in
general).
It would be really nice if none of the "common" commands had a hyphen
in them, for example.
And then, the next phase of my evil plan would be to introduce a -i
option for git-commit making it commit the state in the index. Then
git-commit with no options could work like "git-commit -a" does now,
(with the additional protection of not committing any unmerged
files---that is the new "git resolve" would be required before "git
commit" would work after a conflict). Users who really, really like
the current behavior of git-commit could use the new alias support to
pass the new -i option in order to maintain compatible behavior.
Then, the last thing I'd really like to fix is to allow a usage of
"git merge <branch>" instead of the awkward "git pull . <branch>".
With that, most of the user-interface warts that I regularly run into
with git would be solved. Oh, except it would also be nice to
eliminate the "plumbing" commands in a couple of places:
1) From the "man git" man page
2) From git-<TAB>, (maybe the solution for this is to make
"git <TAB>" work and only do tab-completion for the commands
blessed enough to appear in "git --help"? Also push the tab
completion stuff out as a standard part of packages.
Anyway, now I've just gone and blown all my secret plans for changing
git in ways to make it less intimidating for new users.
For reference, the latest potential batch of new users that I'm
dealing with is the set of Fedora package maintainers who are looking
at replacing CVS for their tree of package-building scripts. They are
currently evaluating systems and liking the interface of hg. Here's
the top of the current thread:
https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00030.html
Here's the report about "git commit -a" confusion that led to my patch
above:
https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00141.html
And here's my reply where I suggest that git UI might still be
improved in these areas:
https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00149.html
-Carl
Attachment:
pgpKjZiwFC77I.pgp
Description: PGP signature