"Elijah Newren" <newren@xxxxxxxxx> writes: > The page http://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws > contains a number of claimed UI flaws of git. I suspect that a number > of them are out-of-date; it doesn't seem to jive with my recent > reading of the documentation. Could anyone point out which are still > accurate with recent git, and which aren't? I'll examine them point by point, and write replies when I know the answer. Probably should correct wiki page, too... > * 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. If I remember correctly there was some work done on cherry-picking, reverting (revert is cherry-picking reverse of a commit in the diff -R or patch -R sense) and rebase with multiparent commits, telling which of parent to treat. But I do not remember details. The advice is of no use: git-show for merge (multi-parent) commits either doesn't show diff at all, or show compact combined diff (diff --cc) which cannot be applied. Another issue of note is that "git revert" does not roll back the tree state, but applies reversion of given change, i.e. reverts / undoes given _changeset_. > * '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. No, I would never expect git-rebase to fetch somthing. And "git rebase <upstream>" is *not* no-op: it rebases (rebuilds) _current_ branch on top of given branch. To do fetch+rebase, i.e. update branch in rebase based workflow, use "git pull --rebase". > * 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): - 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 So 'foo' is treated as 'foo:' (which means fetch, and not store), and not as 'foo:foo'. It is perhaps a bit strange, but backward compatibility would I think prohibit us to change it, even if it would make more sense to have it be shortcut for 'foo:foo' instead. Besides now that we have git-remote it might be a moot point: setting up remotes and remote branches info is very easy now. > * 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. It is git-add now, not git-update-index. I'm not sure what is exact wording of interrupted rebase in current git, as it was some time since I used it, but IIRC it talks about "resolving conflicts", and doing "git add"[*1*] is a part of this step. [*1*] There is/was a floating idea to add "git resolved" command, which would be limited porcelain calling git-update-index, used _only_ to mark resolved conflicts, and having checks etc. for that. > * The command to merge branch B onto branch A is not > "git-merge A B". Instead it's "git-checkout A && git-pull . B". Long fixed, although not in the matter mentioned. To merge branch B into _current_ branch (you cannot merge to non-current branch because of possibility of conflicts) you can use "git merge B". > * 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). It is possible with globbing refspec, like this example: "refs/heads/*:refs/remotes/origin/*". You can use git-remote to do this for you. > * 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. There is now branch.<name>.merge configuration variable to change the "first pull line" default; note that globbing refspec requires this, IIRC. > * 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. This was I guess written in the "git is not an SCM' times. Those are long past, gone with Cogito ;-) > * The index should be second-class, i.e. no -a flags to avoid the > index. To much opposition for that. Adding '-a' option is not such a burden (you most probably ass '-s' option anyway), and you can always use alias for this. > * branch:branch-origin (or something) should be the default pull. You can configure from which remote to fetch (to pull) with branch.<name>.remote, and which branch to merge with branch.<name>.merge. And branch.autosetupmerge if you want git to set this up for you... > * branch:branch should be the default push for all branches, but > only push the current branch unless a flag is added. You can now push only current branch with "git push <remote> HEAD", and IIRC also with magic "git push HEAD". There was talk about whether make current --matching, or proposed --current, behaviour the default for git-push. Any changes in behavior must be done with long obsolescence period (half a year for git). > * An update command should be created that: > * 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. Not done, and probably has no much sense otherwise (merging is done using 3-way merge, not by taking diff and applying it as a patch). > Infrastructure/git/UIFlaws (last edited 2007-06-03) -- Jakub Narebski Poland ShadeHawk on #git -- 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
