Git user survey and `git pull`

Git user survey and `git pull`

[Shawn Pearce]

I just saw this comment under question 20:

    git-pull's behavior of merging in the first refspec to the
    current branch is very bad and has caused us serious repository
    issues in xorg.

Most of the folks I've been teaching Git to recently have found `git
fetch` to be a very counterintuitive command for fetching things.
Especially since `git push` is what's used to send changes to
the remote repository.  They also find `git pull . foo` as a
counterintuitive way to merge changes.

Basically I'm seeing users run `git pull` when they probably
should have run just `git fetch`; the pull obviously also merges
the first refspec in .git/remotes/origin to the current branch
and that's usually not what the user wanted, especially when the
upstream remote has several branches that the user may be tracking
(e.g. stable, dev, experimental).


I think its probably too late to change the UI[*1*] but I think
it is definately an issue for folks learning Git.  Calling push
push, fetch fetch and fetch+merge pull is probably a design flaw.
IMHO it probably should have been something like:

  Current            Shoulda Been
  ---------------    ----------------
  git-push           git-push
  git-fetch          git-pull
  git-pull . foo     git-merge foo
  git-pull           git-pull --merge
  git-merge          git-merge-driver

in other words pull does the download and doesn't automatically
start a merge unless --merge was also given and git-merge is a
cleaner wrapper around the Grand Unified Merge Driver that makes
it easier to start a merge.


[*1*] I bet a lot of scripts are currently based on the core
      Git Poreclain level functions.  I try to avoid them myself
      in scripts and go right to the plumbing but not everyone
      does that.

-- 
Shawn.

Re: Git user survey and `git pull`

[Petr Baudis]

Dear diary, on Thu, Sep 21, 2006 at 06:24:01PM CEST, I got a letter
where Shawn Pearce <spearce@spearce.org> said that...
> in other words pull does the download and doesn't automatically
> start a merge

This is artifact of the BitKeeper terminology. This is the meaning in
most other VCSes but in BitKeeper, pull meant "get changes and merge
them", not just "get changes". So the BitKeeper legacy lives on. :-)

The route I took for Cogito is to just avoid calling _any_ command
"pull". It's too confusing. "update" does the same as "cvs update" or
"svn update" and I didn't notice people having much problem with that.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Re: Git user survey and `git pull`

[Nicolas Pitre]

On Thu, 21 Sep 2006, Shawn Pearce wrote:

> I think its probably too late to change the UI[*1*] but I think
> it is definately an issue for folks learning Git.  Calling push
> push, fetch fetch and fetch+merge pull is probably a design flaw.
> IMHO it probably should have been something like:
> 
>   Current            Shoulda Been
>   ---------------    ----------------
>   git-push           git-push
>   git-fetch          git-pull
>   git-pull . foo     git-merge foo
>   git-pull           git-pull --merge
>   git-merge          git-merge-driver
> 
> in other words pull does the download and doesn't automatically
> start a merge unless --merge was also given and git-merge is a
> cleaner wrapper around the Grand Unified Merge Driver that makes
> it easier to start a merge.

I must say that I second this.  Although I'm rather familiar with GIT I 
still feel unconfortable with the current naming and behavior.


Nicolas

Re: Git user survey and `git pull`

[Shawn Pearce]

Nicolas Pitre <nico@cam.org> wrote:
> On Thu, 21 Sep 2006, Shawn Pearce wrote:
> >   Current            Shoulda Been
> >   ---------------    ----------------
> >   git-push           git-push
> >   git-fetch          git-pull
> >   git-pull . foo     git-merge foo
> >   git-pull           git-pull --merge
> >   git-merge          git-merge-driver
> > 
> > in other words pull does the download and doesn't automatically
> > start a merge unless --merge was also given and git-merge is a
> > cleaner wrapper around the Grand Unified Merge Driver that makes
> > it easier to start a merge.
> 
> I must say that I second this.  Although I'm rather familiar with GIT I 
> still feel unconfortable with the current naming and behavior.

The only way I've been able to resolve it internally is to say:

    ``I can pull the changes contained in branch foo into
	  my current working branch by `git pull . foo`.  I'm
	  not merging changes, I'm pulling them.``

Uh, yea....

As a prior user of a popular VCS which was also used by some folks
on LKML and which also had a 'pull=fetch+merge' command I fully
understand why its pull in Git - but I don't like it.

-- 
Shawn.

Re: Git user survey and `git pull`

[Johannes Schindelin]

Hi,

On Thu, 21 Sep 2006, Nicolas Pitre wrote:

> On Thu, 21 Sep 2006, Shawn Pearce wrote:
> 
> > I think its probably too late to change the UI[*1*] but I think
> > it is definately an issue for folks learning Git.  Calling push
> > push, fetch fetch and fetch+merge pull is probably a design flaw.
> > IMHO it probably should have been something like:
> > 
> >   Current            Shoulda Been
> >   ---------------    ----------------
> >   git-push           git-push
> >   git-fetch          git-pull
> >   git-pull . foo     git-merge foo
> >   git-pull           git-pull --merge
> >   git-merge          git-merge-driver
> > 
> > in other words pull does the download and doesn't automatically
> > start a merge unless --merge was also given and git-merge is a
> > cleaner wrapper around the Grand Unified Merge Driver that makes
> > it easier to start a merge.
> 
> I must say that I second this.  Although I'm rather familiar with GIT I 
> still feel unconfortable with the current naming and behavior.

Originally, I wanted to shut up about this issue. But since there are two 
voices against the current naming, I want to speak for it.

When I was introduced to CVS, _I_ found the _CVS_ names misleading. I 
thought that cvs update would throw away my changes.

So let's face it, a single name cannot possibly convey the meaning to that 
many people, and therefore, it is _necessary_ to have a nice short 
introduction, after which users actually know that git-pull is a fetch + 
merge. Once you know it, what can possibly go wrong? ;-)

Ciao,
Dscho

Re: Git user survey and `git pull`

[Jakub Narebski]

Nicolas Pitre wrote:

> On Thu, 21 Sep 2006, Shawn Pearce wrote:
> 
>> I think its probably too late to change the UI[*1*] but I think
>> it is definately an issue for folks learning Git.  Calling push
>> push, fetch fetch and fetch+merge pull is probably a design flaw.
>> IMHO it probably should have been something like:
>> 
>>   Current            Shoulda Been
>>   ---------------    ----------------
>>   git-push           git-push
>>   git-fetch          git-pull
>>   git-pull . foo     git-merge foo
>>   git-pull           git-pull --merge
>>   git-merge          git-merge-driver
>> 
>> in other words pull does the download and doesn't automatically
>> start a merge unless --merge was also given and git-merge is a
>> cleaner wrapper around the Grand Unified Merge Driver that makes
>> it easier to start a merge.
> 
> I must say that I second this.  Although I'm rather familiar with GIT I 
> still feel unconfortable with the current naming and behavior.

Using git-pull . <branch> for _merge_, and git-merge being mid-level
command (one of the arguments is <msg>, instead of having git-commit like
ways to provide/amend commit message) is somewhat confusing.

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Git user survey and `git pull`

[Linus Torvalds]

On Thu, 21 Sep 2006, Petr Baudis wrote:
> 
> This is artifact of the BitKeeper terminology. This is the meaning in
> most other VCSes but in BitKeeper, pull meant "get changes and merge
> them", not just "get changes". So the BitKeeper legacy lives on. :-)

Indeed. "pull/push" are the operations bk has. 

BK doesn't have branches, and cannot do a "fetch", so there's no confusion 
in BK - the pulls and the pushes are not mirror-images, but since there 
are no other operations you'd normally use, you can pretty much ignore it.

(That's not entirely true. In BK, you can do "bk receive" and "bk resolve" 
to "fetch" and "merge" another branch, but quite frankly, I personally 
found them so confusing that I never used them at all).

I agree that the clarifications from Shawn are probably improvements, but 
I'd actually like to solve the problem a bit differently. Namely, I was 
hoping that the per-branch configuration would solve the confusion.

Right now, a plain "git pull" means "fetch all branches and merge the 
first one", and the thing is, that's generally the right thing _only_ if 
you pull into "master".

It's usually exactly the _wrong_ thing to do for any other branch. In 
particular, if you work with a project that has lots of branches, and 
you're working in another branch (that is directly tracking a remote, for 
example), doing a "git pull" definitely should _not_ merge the first head. 
It should fetch everything, and possibly merge the _matching_ head.

Which it doesn't do right now.

So I think the problem with "git pull" is not that it's a "fetch and 
merge", it's that it merges the wrong head. It always merges the first 
remote one (aka the remote "HEAD"), regardless of which head we happen to 
be at right now.

So I was kind of hoping that the per-branch configuration stuff (that 
petered out after the .git/config file format was worked out) would solve 
the problem.

That said, maybe Shawn's suggestion is better. And maybe the fact that 
we'd change the semantics mid-stream would make things even WORSE. I 
dunno.

		Linus

Re: Git user survey and `git pull`

[Nicolas Pitre]

On Thu, 21 Sep 2006, Linus Torvalds wrote:

> Right now, a plain "git pull" means "fetch all branches and merge the 
> first one", and the thing is, that's generally the right thing _only_ if 
> you pull into "master".
> 
> It's usually exactly the _wrong_ thing to do for any other branch. In 
> particular, if you work with a project that has lots of branches, and 
> you're working in another branch (that is directly tracking a remote, for 
> example), doing a "git pull" definitely should _not_ merge the first head. 
> It should fetch everything, and possibly merge the _matching_ head.
> 
> Which it doesn't do right now.

I think you're summarizing my grip about git pull quite well.  This is 
really counter-intuitive and I've been bitten by that behavior on many 
occasions.


Nicolas

Re: Git user survey and `git pull`

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> I agree that the clarifications from Shawn are probably improvements, but 
> I'd actually like to solve the problem a bit differently. Namely, I was 
> hoping that the per-branch configuration would solve the confusion.
>
> Right now, a plain "git pull" means "fetch all branches and merge the 
> first one", and the thing is, that's generally the right thing _only_ if 
> you pull into "master".
>
> It's usually exactly the _wrong_ thing to do for any other branch. In 
> particular, if you work with a project that has lots of branches, and 
> you're working in another branch (that is directly tracking a remote, for 
> example), doing a "git pull" definitely should _not_ merge the first head. 
> It should fetch everything, and possibly merge the _matching_ head.
>
> Which it doesn't do right now.

I am actually in favor of adding config mechanism that lets you
say things like:

  When on branch 'foo':

  - pull without any argument shall use .git/remotes/$that,
    instead of the usual .git/remotes/origin;

  - pull without pathspec arguments shall use the named
    .git/remotes/ file to learn from which URL to fetch from,
    which remote branches to fetch and which local branches to
    store them, but merge $this_and_that remote heads regardless
    of what .git/remotes/ file says;

  - you shall not use "reset" other than resetting to the HEAD;

  - you shall not use "rebase";

  - you shall not merge from $this_and_that branches;

  - your commit identity shall be $whoami, not the usual
    core.user;

I am not motivated enough to do that myself, though.

Re: Git user survey and `git pull`

[Santi]

2006/9/22, Junio C Hamano <junkio@cox.net>:
> I am actually in favor of adding config mechanism that lets you
> say things like:
>
>   When on branch 'foo':
>
>   - pull without any argument shall use .git/remotes/$that,
>     instead of the usual .git/remotes/origin;
>
>   - pull without pathspec arguments shall use the named
>     .git/remotes/ file to learn from which URL to fetch from,
>     which remote branches to fetch and which local branches to
>     store them, but merge $this_and_that remote heads regardless
>     of what .git/remotes/ file says;
>

Something like
http://marc.theaimsgroup.com/?l=git&m=115398815111209&w=2
?

  Santi

Re: Git user survey and `git pull`

[Junio C Hamano]

Santi <sbejar@gmail.com> writes:

> Something like
> http://marc.theaimsgroup.com/?l=git&m=115398815111209&w=2
> ?

I do not have access to marc at the moment but I have saved a
patch from you back from July in one of my freezer mbox.  IIRC
your message was not for inclusion but more as a firestarter for
discussions, and the discussion never came to conclusion with 
appliable set of patches.

Re: Git user survey and `git pull`

[Matthias Urlichs]

For what it's worth, I'm in favor of renaming the things.

IMHO, we do not need that kind of baggage. Sure, you explain it once and
people hopefully remember -- except that they don't, not always anyway,
and novice users can't be expected to be notice, let alone repair, that
kind of damage.

*I* make that stupid pull/fetch/merge mistake sometimes, 
and I'm not exactly new to git...


On Thu, 21 Sep 2006 12:24:01 -0400, Shawn Pearce wrote:

>   Current            Shoulda Been
>   ---------------    ----------------
>   git-push           git-push
>   git-fetch          git-pull
>   git-pull . foo     git-merge foo
>   git-pull           git-pull --merge
>   git-merge          git-merge-driver
> 
The new programs can (for the most part) recognize when they're called with
"old" semantics, and spit out a warning.

-- 
Matthias Urlichs

Re: Git user survey and `git pull`

[Santi]

2006/9/22, Junio C Hamano <junkio@cox.net>:
> Santi <sbejar@gmail.com> writes:
>
> > Something like
> > http://marc.theaimsgroup.com/?l=git&m=115398815111209&w=2
> > ?
>
> I do not have access to marc at the moment but I have saved a
> patch from you back from July in one of my freezer mbox.  IIRC
> your message was not for inclusion but more as a firestarter for
> discussions, and the discussion never came to conclusion with
> appliable set of patches.
>

Yes, it was. But I think now will be different :)

In a moment I'll send two little patches for your two first points
(pull w/o arg + pull with just the remote).

Santi

Re: Git user survey and `git pull`

[Jakub Narebski]

Shawn Pearce wrote:

>   git-pull           git-pull --merge

And we can even have "git-pull --merge=<branch to merge to>"

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git

Re: Git user survey and `git pull`

[Alan Chandler]

On Friday 22 September 2006 22:05, Matthias Urlichs wrote:
> For what it's worth, I'm in favor of renaming the things.

Me too.  I am continually coming back to things after a couple of months and 
having to relearn everything from scratch.  I never over the hump of even 
becoming an intermediate user of anything.

-- 
Alan Chandler
http://www.chandlerfamily.org.uk

Re: Git user survey and `git pull`

[Johannes Schindelin]

Hi,

On Fri, 22 Sep 2006, Matthias Urlichs wrote:

> For what it's worth, I'm in favor of renaming the things.
> 
> On Thu, 21 Sep 2006 12:24:01 -0400, Shawn Pearce wrote:
> 
> >   Current            Shoulda Been
> >   ---------------    ----------------
> >   git-push           git-push
> >   git-fetch          git-pull
> >   git-pull . foo     git-merge foo
> >   git-pull           git-pull --merge
> >   git-merge          git-merge-driver
> > 
> The new programs can (for the most part) recognize when they're called with
> "old" semantics, and spit out a warning.

Now, that only introduces more confusion!

If there is another tool rename, better choose names which are virgins. 
Besides, I am still not convinced that the rename is necessary. Granted, 
some new users might get confused with the current naming, but what about 
those who are not? They would be confused by the new naming.

And if you want unambiguous names, and even succeed in choosing sensible 
ones, you can make them hardwired aliases, and old habits don't have to 
die.

Ciao,
Dscho