Linus Torvalds <torvalds@xxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html