Re: Git user survey and `git pull`

From: Junio C Hamano <junkio@cox.net>
Date: Sep 22, 2006, 04:57 UTC
Message-ID: <7vu0305wh8.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.64.0609211027440.4388@g5.osdl.org>

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.