Felipe Contreras <felipe.contre...@gmail.com> writes:
>> Stepping back even further, and thinking what is different between
>> these two pulls, we notice that the first one is pulling from the
>> place we push back to. Perhaps a way to solve this issue, without
>> having to introduce a new 'git update' and updating the tutorials,
>> may be disallow fetch+merge by default only when pulling from the
>> place the result is going to be pushed back to?
> Which is basically essentially the same as not specifying anything, or
> rather, running `git pull` without arguments.
I cannot tell if you are agreeing or disagreeing, and with what.
Using the "special case 'git pull' without arguments" heuristics
would take us back to the old jc/pull-training-wheel patch
which we agreed to drop in
to favor the old series you did with pull.mode, and we rejected that
patch in $gmane/230856 for a sound reason, I would think.
"You are pulling from the place the result is going to be pushed
back to" is different from "'git pull' was run without arguments".
In the "pumpking" example in the message you are responding to:
When he becomes in charge of producing a new 'maint' (in his
original, he says 'maintenance-branch'), he first does this:
$ git checkout maint
$ git pull --ff-only [ origin maint ]
the heuristics would trigger the safety only when the optional
"origin maint" are not given, but we do have enough information
to see "git pull origin maint" (with where from and what to pull
explicitly specified on the command line) falls into the case where
the user needs protection, don't we?
Also, with the triangular push configuration, "git pull" without
argument will fetch from one place that is different from where the
current branch is going to pushed to, so that heuristics would not
work at all.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html