"W. Trevor King" [off-list ref] writes:
On Fri, Jun 28, 2013 at 08:34:53AM +0200, Matthieu Moy wrote:
quoted
"W. Trevor King" [off-list ref] writes:
quoted
Or they may not even realize that they've just merged an unrelated
branch at all, dragging in a thousand unrelated commits which they
accidentally push to a central repository without looking,
contaminating future branches based on the central repostitory without
drastic rebase surgery ;). I just saw one of these earlier this week.
I don't understand how the change would solve this. If "pull" would drag
a lot of commits in the current branch, the "rebase" will rebase the
current branch on a totally different history, and pushing the result
would be equally bad.
I want the warning that they had not made the required config choice
between rebase/merge needed to handle a non-ff case, not the default
merge (or rebase) behavior. The warning gives them a chance to
realize that this was not an appropriate time for a `svn update`
analog, and that the project may not to want to have the branches
joined at all ;).
You're assuming that the config is not made, but this is supposed to
happen once initially. Then, the user will chose either merge or rebase,
and whatever is chosen, the result will be bad.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
On Fri, Jun 28, 2013 at 01:52:38PM +0200, Matthieu Moy wrote:
"W. Trevor King" [off-list ref] writes:
quoted
I want the warning that they had not made the required config choice
between rebase/merge needed to handle a non-ff case, not the default
merge (or rebase) behavior. The warning gives them a chance to
realize that this was not an appropriate time for a `svn update`
analog, and that the project may not to want to have the branches
joined at all ;).
You're assuming that the config is not made, but this is supposed to
happen once initially. Then, the user will chose either merge or rebase,
and whatever is chosen, the result will be bad.
I'm hoping that reading the error message reminds them that these
cross-branch pulls are not recommended (for us), and that they skip
the configuration step (so they'll get the same warning after their
next subconcious pull). Of course, there are no guarantees. But if
they do configure their rebase/merge preference and make and push bad
merge, at least I'll have something I can suggest as a finger-breaker.
Of course, they should already be seeing their editor with a merge
commit message that they are ok-ing. If that's not enough to make
them think twice, a warning that:
The pull does not fast-forward; …
may fall on deaf ears (blind eyes?). However, for folks used to only
having a single branch, this may be enough of a jolt to wake them up.
I'm not making a very strong case, and this whole line of reasoning is
getting off topic for this PR. Unless we adapt it to:
pull.non-ff = {merge,rebase,never}
which is, I think, even less likely to land ;).
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy