This page attempts to document the most egregious git UI offenses, in the hope that they'll get fixed someday.
Update: Since this page was created Git has come a long way. All of the issues listed have been addressed and this page should probably be retired.
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). Solved: git remote update
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. Solved: the "merge" variable in the config holds which branch to merge by default
git-fetch requires that the branch be named on both sides of the :. It should treat foo as an alias for foo:foo. Solved: the config now holds the associated remote to fetch by default
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. Solved: git revert -m1
The command to merge branch B onto branch A is not git-merge A B. Instead it's git-checkout A && git-pull . B. Solved: The documentation now makes it clear that you can only merge with checked out branch, eg. git checkout A && git merge B
branch:branch-origin (or something) should be the default pull. Solved: config holds which branch to fetch and merge for each local branch
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. Solved: User is informed of proper steps (git add, etc)
branch:branch should be the default push for all branches, but only push the current branch unless a flag is added. Solved: the config holds a mapping of local branch name to remote branch name so there is no need to give it on command line
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. Solved: Documentation makes it clear that Git is designed to work offline; users should not expect network activity for local operations
An update command should be created that: Solved: git pull --no-commit performs the operations as outlined below
- fetches the current branch's upstream to its -origin locally (or all branches, perhaps);
- merges the current branch origin to the branch locally;
- commits if it was a fast-forward, and leaves uncommitted diffs otherwise.
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. Solved: Fundamentally this wasn't ever a problem, but Git is now just a single command "git" with sub-commands
The index should be second-class, i.e. no -a flags to avoid the index. Solved: Documentation is more clear now. Users can choose one of many GUI's and avoid command line altogether if they find -a hard to type