threads / discuss / 5639

Git user survey and `git pull`

Subject: Git user survey and `git pull`

## tl;dr

16 messages between Sep 21, 2006 and Sep 23, 2006.

replies: 15people: 10as markdown or json

Shawn Pearce· Sep 21, 2006, 16:24 UTC · lore

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.

Petr Baudis· Sep 21, 2006, 16:40 UTC · re: Shawn Pearce · lore

Re: Git user survey and `git pull`

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*',/((..)*)$/)

Linus Torvalds· Sep 21, 2006, 17:38 UTC · re: Petr Baudis · lore

Re: Git user survey and `git pull`

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

Nicolas Pitre· Sep 21, 2006, 18:05 UTC · re: Linus Torvalds · lore

Re: Git user survey and `git pull`

On Thu, 21 Sep 2006, Linus Torvalds wrote:

Show 11 quoted lines

> 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

Junio C Hamano· Sep 22, 2006, 04:57 UTC · re: Linus Torvalds · lore

Re: Git user survey and `git pull`

Linus Torvalds <torvalds@osdl.org> writes:

Show 15 quoted lines

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

Santi· Sep 22, 2006, 10:34 UTC · re: Junio C Hamano · lore

Re: Git user survey and `git pull`

2006/9/22, Junio C Hamano <junkio@cox.net>:

Show 14 quoted lines

> 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

Junio C Hamano· Sep 22, 2006, 19:08 UTC · re: Santi · lore

Re: Git user survey and `git pull`

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.

Santi· Sep 22, 2006, 23:24 UTC · re: Junio C Hamano · lore

Re: Git user survey and `git pull`

2006/9/22, Junio C Hamano <junkio@cox.net>:

Show 12 quoted lines

> 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

Nicolas Pitre· Sep 21, 2006, 17:02 UTC · re: Shawn Pearce · lore

Re: Git user survey and `git pull`

On Thu, 21 Sep 2006, Shawn Pearce wrote:

Show 17 quoted lines

> 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

Shawn Pearce· Sep 21, 2006, 17:09 UTC · re: Nicolas Pitre · lore

Re: Git user survey and `git pull`

Nicolas Pitre <nico@cam.org> wrote:

Show 16 quoted lines

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

Johannes Schindelin· Sep 21, 2006, 17:12 UTC · re: Nicolas Pitre · lore

Re: Git user survey and `git pull`

Hi,

On Thu, 21 Sep 2006, Nicolas Pitre wrote:

Show 22 quoted lines

> 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

Jakub Narebski· Sep 21, 2006, 17:17 UTC · re: Nicolas Pitre · lore

Re: Git user survey and `git pull`

Nicolas Pitre wrote:

Show 22 quoted lines

> 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

Matthias Urlichs· Sep 22, 2006, 21:05 UTC · re: Shawn Pearce · lore

Re: Git user survey and `git pull`

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:

Show 8 quoted lines

>   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

Alan Chandler· Sep 23, 2006, 11:51 UTC · re: Matthias Urlichs · lore

Re: Git user survey and `git pull`

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

Johannes Schindelin· Sep 23, 2006, 14:12 UTC · re: Matthias Urlichs · lore

Re: Git user survey and `git pull`

Hi,

On Fri, 22 Sep 2006, Matthias Urlichs wrote:

Show 14 quoted lines

> 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

Jakub Narebski· Sep 23, 2006, 08:54 UTC · re: Shawn Pearce · lore

Re: Git user survey and `git pull`

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