On Tue, 10 Jun 2008, Andreas Ericsson wrote: > 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... > 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: > 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. > * 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. > * "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? > * 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. > * 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. > * 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. > * 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. > * 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. > * 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...). > * 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. > * 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. > * 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. > * 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
