On Tue, 10 Jun 2008, Andreas Ericsson wrote:

quoted text
> I just stumbled across this freedesktop.org site from 2007-06-03:
> http://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws
> 
> It seems to me that since then most of the issues have been worked
> out.  Are any of them still valid points? If so, which ones and how
> should we go about addressing them?

See below for detailed response.  It looks like all, or almost all 
issues got addressed...
 
quoted text
> Jakub Cc'd as he was the last one to edit the (now immutable) wiki
> page. 

I wonder why it was made immutable (static page)... errr, it is not 
immutable, you just are required to login to edit.

Below detailed analysis of the contents of the page

-------------------------------------------------------------------
Infrastructure/git/UIFlaws:

quoted text
> This page attempts to document the most egregious git UI offenses,
> in the hope that they'll get fixed someday. It would be pleasant if
> git had a bugzilla. In git's defence, 1.5 appears to be making great
> strides towards usability.   

I'm not sure if having bug tracker would help.  Git development works 
quite well with RelNotes, git mailing list and its searchable archives.

quoted text
> * git-revert will refuse to back out multi-parent commits, ie, merges.
>   The obvious behaviour is to do basically what 
>      git-show [commit] | patch -p1 -R
>   would do, ie, roll back the tree state to the branch you came from.

Git has now "-m <parent-number>|--mainline <parent-number>" option to 
git-cherry-pick and git-revert, which would allow to revert merge 
commit.  You usually don't want to do this, by the way.

quoted text
> * "git rebase foo" is a noop, when foo is the name of local branch.
>    You would expect it to fetch the branch named foo from upstream,
>    and rebase your foo branch on top of it.

Use "git pull --rebase" for this.

You wouldn't expect "git merge" to _fetch_ from upstream (would you?), 
so why "git rebase" would be expected to fetch?

quoted text
> * git-fetch requires that the branch be named on both sides of the :.
>   It should treat foo as an alias for foo:foo. 

From git-fetch(1) manpage:

   Some short-cut notations are also supported
   [...]

   *  A parameter <ref> without a colon is equivalent  to  <ref>:  when
      pulling/fetching,  so  it  merges  <ref>  into the current branch
      without storing the remote branch anywhere locally

There was discussion on git mailing list on changing this default, but 
among others backward compatibility prevents it.  That and the fact 
that current behavior makes most sense (usually with git-pull, not 
git-fetch) for one-shot fetches; if you want to contact given 
repository periodically, you would set up remote configuration (using 
git-remote for example) and wouldn't use refspecs anyway.

quoted text
> * git-rebase claims you should git-rebase --continue after you fix up
>   the merges; it really means you should git-update-index followed by
>   git-rebase --continue.

(Actually now it is git-add, not git-update-index).

I don't know if it changed.  There was recurring idea about adding 
"git resolved" command, but it was never implemented, probably because 
it would add another comand to already large set, an that its name and 
a bit semantic were not sufficiently clear.  git-mergetool should 
reduce occurences where you have to manually git-add before continuing 
rebase.

quoted text
> * The command to merge branch B onto branch A is not git-merge A B.
>   Instead it's git-checkout A && git-pull . B.

It _cannot_ be "git merge A B", as there can be conflicts, so one side 
_has_ to be checked out.  But nowadays "git checkout A && git merge B"
is enough, and you don't have to use bit cryptic "git pull . B" syntax.

quoted text
> * There is no way to tell git-fetch (or therefore git-pull) to grab
>   all newly available branches. You have to ask for them by two names
>   (as above), and then there's no way to get those names automatically
>   into your remotes list (also as above).

With globbing refspecs it is now possible.

quoted text
> * git pull's default behaviour on a branch is unhelpful: even when
>   there is an explicit Pull: branch1:branch1 line, a git pull with
>   branch1 checked out will still pull in master.

You can now use branch configuration to avoid this confusion, I think.

quoted text
> * Fundamentally, the entire approach of making the UI painful to deal
>   with and forcing the user to deal with all the warts (instead of
>   just making the hairy low-level commands available), because people
>   will write nice wrappers around it, is the same reason people
>   laughed at tla, and still do.

Errr, what?!?  The idea never was to make UI horrible.  The idea was 
bottom-up approach, building low-level plumbing first, and evolving 
porcelain commands next (with a bit of help from Cogito...).

quoted text
> * The index should be second-class, i.e. no -a flags to avoid the
>   index.

Well, Linux and Junio disagree.  

Beside, having index visible is useful, and sometimes necessary.

quoted text
> * branch:branch-origin (or something) should be the default pull.

"git remote add <name> <url>" sets up globbing refspec in the form
'refs/heads/*:refs/remotes/<name>/*'.  

"origin" remote is default remote ("git pull"), but you can set 
different remotes, even per branch default remotes.

I don't know which of this thing author wanted to have.

quoted text
> * branch:branch should be the default push for all branches, but only
>   push the current branch unless a flag is added.

Long discussion on git mailing list about "git push --current" vs 
"git push --matching" and which should be the default.  You can push 
current branch now with "git push <remote> HEAD" (or I think even with 
"git push HEAD"), changing the default for the backwards compatibility 
reasons would have to wait, even if we agree that it is a good change.

quoted text
> * An update command should be created that:
>      o fetches the current branch's upstream to its -origin locally
>        (or all branches, perhaps); 
>      o merges the current branch origin to the branch locally;
>      o commits if it was a fast-forward, and leaves uncommitted
>        diffs otherwise. 

There is "git remote update", there are globbing refspecs, there is (or 
would be) --ff / --ff=only option and --no-commmit option... what I am 
not sure if the workflow described is actually useful... especially 
with easy rollback in "git reset --hard ORIG_HEAD" and "git commit 
--amend" at fingertips.

-- 
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html