Re: What's in git.git (stable)

From: Junio C Hamano <junkio@cox.net>
Date: Dec 22, 2006, 18:58 UTC
Message-ID: <7vwt4jzrjb.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <86fyb7sv9f.fsf@blue.stonehenge.com>

merlyn@stonehenge.com (Randal L. Schwartz) writes:

Show 15 quoted lines

>>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
>>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
> Junio> git-pull: refuse default merge without branch.*.merge
>
> Randal> Argh.  How do I get back the old behavior?
> Randal> "git-pull origin" doesn't seem to be enough.
>
> Randal> You just broke a bunch of automated scripts for me.
>
> Ahh, it's "git-pull . origin".
>
> Maybe a bit more warning for non-upward-compatible changes though, please.
>
> Or maybe we should presume everything is non-upward compatible?  I didn't
> think a naked "git-pull" was that out of the ordinary.

Things are supposed to be upward compatible, but this round until v1.5.0 some things may not be when it is justifiably an improvement. For example, we've already made 'separate remote' not only the default but the only layout 'git clone' produces. I cannot think of others offhand, but I am reasonably certain there are others. We need a "incompatible changes" list.

The tradtional "pull always merges the first set of branches" rule, although I was actually very much in favor of it, was something that was hated by everybody.

It was said that people had lot of trouble after doing "git pull origin" without any refspecs ("git pull" without any argument defaults to 'origin' which is backward compatible, if you do not have branch.*.remote, so that form has the same issues), when on a branch other than the 'master' branch. "merges the same first set of branches no matter which branch you are on" was the rule, but people did not want to merge the ones they usually merge to their 'master' but wanted some other branch merged. "branch.*.merge" can be used to specify this, but if you do not have need for this "merge different branches depending on which branch I am on", you do not have to use it. Without "branch.*.merge" for the current branch, we are still backward compatible and follow the "first set of branches" rule.

The real trouble is that some people further argued that pulling without 'branch.*.merge' when you might not want to follow the "first set of branches" rule might be a newbie mistake and should be warned and forbidden. The commit that broke you was an attempt for that behaviour. I think that newbie protection intent is good, but the execution was obviously not.

What I have on 'master' has a little fixup to use 'first set of branches' rule when the fetch gets only one branch without complaining. I am still not happy with that either, and at this point I am not sure if there is a good compromise that does not break existing setup while offering the newbie protection.

Possibilities:

 (1) Forget about that "protection" business.  If you do not
     want mistakes, use 'branch.*.merge' but otherwise we will
     continue to follow the good old "first set of branches"
     rule.

 (2) A slight variant of the above; do the "protection" only
     when 'branch.*.merge' is defined for _any_ of the branches,
     not just the current branch.

 (3) A further variant; do not do the above "protection" if the
     current branch is 'master' (this further makes 'master'
     special, which some people may hate).