Which freedesktop.org "design flaws" in git are still relevant?

Hi,

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?

Thanks, Elijah

On Fri, 29 Feb 2008, Elijah Newren wrote:

It says:

	Infrastructure/git/UIFlaws (last edited 2007-06-03 18:41:26 by 
	JakubNarebski) 

and despite being updated almost 9 months ago, the content feels even older than that.

Jakub?

Nicolas

On Fri, 29 Feb 2008, Nicolas Pitre wrote:

http://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws?action=info

I have just fixed one error there, and didn't take time to correct all the things.

P.S. I have replied in another message in this thread, discussion those mentioned "flaws" one by one.

"Elijah Newren" <newren@gmail.com> writes:

I'll examine them point by point, and write replies when I know the answer. Probably should correct wiki page, too...

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_.

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".

   - 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.

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.

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".

It is possible with globbing refspec, like this example: "refs/heads/*:refs/remotes/origin/*". You can use git-remote to do this for you.

There is now branch.<name>.merge configuration variable to change the "first pull line" default; note that globbing refspec requires this, IIRC.

This was I guess written in the "git is not an SCM' times. Those are long past, gone with Cogito ;-)

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.

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...

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).

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).

Jakub Narebski <jnareb@gmail.com> writes:

It is not strange nor b/c requirement at all. If anything, it could default to "foo:remotes/$remote/foo", not "foo:foo", but even then, it shouldn't.

You are missing a bigger picture. I think the list predates the introduction of separate remotes, which has been the default for more than a year.

You would have "fetch = refs/heads/*:refs/remotes/origin/*" these days in the configuration by default. What this means is that you would have much less reason to run "fetch $there foo" to begin with. The only time you would fetch in that way is when you want an unconfigured, single-shot fetch, in which case you do _NOT_ want tracking. So there is no valid reason to default "foo" to "foo:<anything>", unless that <anything> is empty. Not to foo:foo, not to foo:remotes/$remote/foo.

Many of the remaining parts of the complaint list share the misunderstanding coming from the lack of understanding of separate remotes layout.

On Fri, 29 Feb 2008, Jakub Narebski wrote:

I think the idea there is "git diff $1 $1^ | git-apply"; that is, reverting the content changes between the merge and its (first) parent.

Furthermore, you can rebase branches on other local branches. (E.g., if I realize that I need in speculative branch A a fix I made in maintence branch B, I'll rebase A on B so that, when B hits mainline, rebasing A on it will do the right thing and get B out of the series.)

Actually, what would make sense would be, perhaps, to update local tracking branches that match a fetch "foo:". For that matter, you *really* don't want "foo" to mean "foo:foo", because "foo:foo" is undesireable; you want "foo:origin/foo" or something of that sort.

I think it's still not terribly explicit in the instructions for resolving the conflicts. I think the worse thing is that you have to pick out the conflicting files from the ones that were handled, rather than getting a section of "fix <list of files>, mark them handled with "git add", and continue".

I have to wonder if this person actually wants: "git merge A && git push . A" (which is to say, resolve the conflicts on the topic branch and update the mainline branch with the now-fast-forward result). Of course, there's no major need for a local A branch, but that's often not obvious to new users.

Heck, git clone does this for you these days.

I wonder if commit shouldn't use -a by default if there are changes but none staged. But people adding new files would trip over that.

The *real* magic is "remote.*.push: HEAD". (The reason it's real magic is that I implemented it, and I didn't know I'd implemented it until Junio mentioned it in release notes. Validation of the design of a weak UI around a strong core.)

Actually, isn't this "git pull --no-commit"? It:

 * fetches the current branch's remote, updating the tracking refs for it 
   (not branch-origin, but remotes/origin/*, a better name)
 * merges the remote branch in "merge" for the current branch into the 
   current branch
 * if it was not a fast-forward (if it was, there's no new state to leave 
   uncommitted), it doesn't commit it, but leaves the changes merged (or 
   conflicting, if there were conflicts) in the index.

Nobody agrees on what, exactly, "git update" should do, but I think all of the sane options are easy aliases. Maybe we should have a recipies section of them. (Actually, it would be amusing to have recipies in a man page for "git update": "It's up to you to make this do what you want. Here are some suggestions...").

I wonder if it would be nice to have per-branch aliases, so that you could have "git update" do whatever is appropriate to update this particular branch, whether it be "git pull --no-commit" or "git reset --hard origin/next && git merge" or "git rebase".

	-Daniel
*This .sig left intentionally blank*

On Fri, Feb 29, 2008 at 4:58 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:

Well, you effectively have this via branch.*.{merge,mergeoptions,rebase,remote}. e.g.:

To effect fetch + non-committing merge:

  branch.<name>.remote        = origin
  branch.<name>.merge         = refs/heads/<name>
  branch.<name>.mergeoptions  = --no-commit

To effect fetch + rebasing:

  branch.<name>.remote        = origin
  branch.<name>.merge         = refs/heads/<name>
  branch.<name>.rebase        = true

(Not sure if there is a way to get "rebase -m" though...)

To effect reset --hard origin/next, add another fetch line to your remote. e.g.:

  [remote "origin"]
    url = git://git.kernel.org/pub/scm/git/git.git
    fetch = +refs/heads/*:refs/remotes/origin/*
    fetch = refs/heads/pu:/refs/heads/pu-readonly

Now "git pull" does the right thing whichever branch I'm on.

j.

On Fri, Feb 29, 2008 at 5:40 PM, Jay Soffian <jaysoffian@gmail.com> wrote:

Obviously missing a '+', though I'm not sure why anyone would do this anyway.

j.

On Fri, 29 Feb 2008, Jay Soffian wrote:

Ah, good point. I'd forgotten mergeoptions.

This case is actually tougher. I've got:

[branch "good-stuff"]
	remote = .
	merge = refs/heads/<local topic I like>
	merge = refs/heads/<another topic>
	merge = refs/heads/<yet another>

This branch is my local equivalent of "pu" for my own topics, which gets next + each topic I have in a testable state (by way of an octopus merge). So I reset to origin/next and merge a lot of local branches.

	-Daniel
*This .sig left intentionally blank*