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

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

[Elijah Newren]

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

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

[Nicolas Pitre]

On Fri, 29 Feb 2008, Elijah Newren wrote:

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

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

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

[Jakub Narebski]

On Fri, 29 Feb 2008, Nicolas Pitre wrote:
> On Fri, 29 Feb 2008, Elijah Newren wrote:
> 
>> 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?
> 
> 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?

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.
-- 
Jakub Narebski
Poland

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

[Jakub Narebski]

"Elijah Newren" <newren@gmail.com> 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

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

[Junio C Hamano]

Jakub Narebski <jnareb@gmail.com> writes:

>> * git-fetch requires that the branch be named on both sides of
>>   the :. It should treat 'foo' as an alias for 'foo:foo'.
>
> 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.

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.

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

[Daniel Barkalow]

On Fri, 29 Feb 2008, Jakub Narebski wrote:

> "Elijah Newren" <newren@gmail.com> 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_.

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.

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

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

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

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.

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

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

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

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.

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

Heck, git clone does this for you these days.

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

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.

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

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

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

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*

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

[Jay Soffian]

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

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

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.

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

[Jay Soffian]

On Fri, Feb 29, 2008 at 5:40 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
>     fetch = refs/heads/pu:/refs/heads/pu-readonly

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

j.

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

[Daniel Barkalow]

On Fri, 29 Feb 2008, Jay Soffian wrote:

> On Fri, Feb 29, 2008 at 4:58 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> 
> > 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".
> 
> 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

Ah, good point. I'd forgotten mergeoptions.

> 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

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*