Re: Git user survey and `git pull`

From: Junio C Hamano <junkio@cox.net>
Date: 2006-09-22 14:57:55
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.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Fri Sep 22 14:58:30 2006

This archive was generated by hypermail 2.1.8 : 2006-09-22 15:00:54 EST