Re: Cleaning up git user-interface warts

[Junio C Hamano <junkio@cox.net>]

Carl Worth <cworth@cworth.org> writes:

> On Tue, 14 Nov 2006 15:52:47 -0500 (EST), Nicolas Pitre wrote:
>> Even if I have a clear preference for GIT's _technology_, I still think
>> that the HG user interface is more convivial.  I even been thinking
>> about writing something like an hg-like frontend to GIT from time to
>> time just so that GIT could then be better compared to (and actually
>> just used like) HG.
>
> I've actually been tempted to do the same myself. I really think that
> the technology is a more important criterion than the UI so the
> imagined hg-on-git interface would be an attempt to get people to look
> past the interface differences and look at the technology when
> deciding.
>...
>> I still think that the GIT user interface sucks in many ways.  The
>...

I've actually been tempted to do that too, and my earlier "if I
were to redo git from scratch" message was the beginning of it
to summarize my preference about some of the issues raised in
this thread.

Commenting on the messages in this thread:

 - "resolve / resolved" are both confusing, when you are talking
   about "mark-resolved" operation.

 - "pull/push/fetch" have undesired confusion depending on where
   people learned the term.  I'd perhaps vote for replacing
   fetch with download and push with upload.

 - I think it would be sensible to make remote tracking branches
   less visible.  For example:

	git diff origin

   where origin is the shorthand for your upstream (e.g. you
   have .git/remotes/origin that records the URL and the branch
   you are tracking) should be easier to understand than

   	git diff remotes/origin/HEAD

   The latter is an implementation detail.  I could imagine we
   might even want to allow

	git diff origin#next

   to name the branch of the remote repository.  The notion of
   "where the tips of remote repository's branches are" is
   probably be updated by "git download" (in other words, the
   above "git diff" does not automatically initiate network
   transfer).

 - "git merge" to merge another branch into the current would
   make sense.  "git pull . remotes/origin/next" is showing too
   much implementation detail.  It should just be:

	git merge origin#next

And I agree with Pasky that fixing UI is hard unless you are
willing to get rid of historical warts.  Syntax of the command
line arguments the current set of Porcelain-ish takes are
sometimes just horrible.  It may not be a bad idea to start
building the fixed UI from scratch, using different prefix than
"git" (say "gu" that stands for "git UI" or "gh" that stands for
"git for humans").

Of course, it could even be "cg" ;-).