On Sun, Sep 08, 2013 at 05:38:50PM -0500, Felipe Contreras wrote:
> Yeah, but the key question at hand in this discussion is; what happens
> when 'git pull' stops working for them, and they don't know what to
> do, will they choose 'git pull --rebase' by mistake?

I agree, they will not choose git pull --rebase by mistake.

> I say the answer is no, because:
> 1) As you say in your scenario, somebody is telling these guys what to
> do, so when 'git pull' fails, somebody will figure out that they were
> doing a merge, so 'git pull --merge' is what they want to type from
> now on.

Yes, that would be me.  My hesitance here is that as the one usually
driving git updates (which so far have happened once a year), I will end
up retraining forty developers.  I don't think the current behavior is
broken or really problematic at all: merging has always been the
default, and people have come to expect that.  People using workflows
that don't want merge have always either needed to set a configuration
option or use --rebase.  As the man page says, --rebase is unsafe, and
that's why it's not the default.

I would be much less unhappy with your earlier change that did not
affect uses with arguments.  That would limit the number of use cases

> 2) Git itself would be warning them for months that a 'non
> fast-forward was found, and a merge will be done for them', so when
> the warning turns to an error, they'll know they want a merge, so
> they'll do 'git pull --merge', either because the warning told them
> that's git was doing all along, or because they figured that out by
> googling, or reading the man page, or whatever.

Again, you assume that git updates happen on a regular basis, and you
assume that most developers really know what happens under the hood.

I don't see a warning now; in fact, I see:

  vauxhall ok % git status
  # On branch master
  # Your branch and 'upstream/master' have diverged,
  # and have 1 and 128 different commits each, respectively.
  #   (use "git pull" to merge the remote branch into yours)

The current behavior of git is to explicitly encourage this behavior,
and now you want to make it not work.  I think this change is a bad
idea, and I think the number of changes required to the test suite
indicates that.  If there's going to be a change here, it should have a
deprecation period with the above message changed and appropriate
warnings, not a flag day; your patches don't do that.

brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Attachment: signature.asc
Description: Digital signature

Reply via email to