Re: Cleaning up git user-interface warts

On 2006-11-14 11:22:39 -0800, Carl Worth wrote:

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).

Yes, "resolve" sounds better than "resolved". The latter is arguably
more correct, since you're telling git that you have already resolved
the file and not asking it to resolve it for you, but I still prefer
"resolve".

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.

Seems very sane. Default to simple behavior, and provide a switch to
get more complicated 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>".

This should reduce newbie confusion a lot.

-- 
Karl Hasselström, kha@treskal.com