Re: [PATCH 0/3] Reject non-ff pulls by default

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Sep 9, 2013, 00:01 UTC
Message-ID: <20130909000153.GG5359@vauxhall.crustytoothpaste.net>
In-Reply-To: <CAMP44s0SLoD7ptgiYOg_vq+Jpo5uhWvzFC8Bd76JHo5zbjf8fg@mail.gmail.com>

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.

Show 6 quoted lines

> 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 affected.

Show 6 quoted lines

> 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