merlyn@xxxxxxxxxxxxxx (Randal L. Schwartz) writes:
>>>>>> "Randal" == Randal L Schwartz <merlyn@xxxxxxxxxxxxxx> writes:
>>>>>> "Junio" == Junio C Hamano <junkio@xxxxxxx> 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).
-
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