Re: Use "git pull --ff-only" by default?

[Michael J Gruber <git@drmicha.warpmail.net>]

Peter Kjellerstedt venit, vidit, dixit 21.05.2010 16:47:
>> -----Original Message-----
>> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
>> Behalf Of Michael J Gruber
>> Sent: den 21 maj 2010 15:49
>> To: Peter Kjellerstedt
>> Cc: git@vger.kernel.org
>> Subject: Re: Use "git pull --ff-only" by default?
>>
>> Peter Kjellerstedt venit, vidit, dixit 21.05.2010 14:59:
>>> Is there some way to make "git pull --ff-only" be the default?
>>> I could not find anything about this in "git config --help" and
>>> also the lack of a --no-ff-only option for git pull (it exists
>>> for git merge) indicates that there is no such support.
>>>
>>> I did considered the branch.<name>.mergeoptions configuration
>>> option, but it does not seem appropriate as it only applies to
>>> a specific branch, whereas I want it to apply to all branches
>>> by default.
>>>
>>> Yes, I know I could do "git config alias.pl 'pull --ff-only'",
>>> but since my intensions are for this to be the default for all
>>> developers in our organization (most of whom have no git knowledge
>>> at all yet) to avoid unnecessary branches caused by the developers
>>> hacking directly on master rather than a topic branch, I would
>>> very much prefer a configuration option rather than an alias (as
>>> I am unlikely to get the developers to remember to do "git pl"
>>> instead of "git pull").
>>
>> Problem is they have to remember to set your new config, or, if you are
>> able to set all developers system config, they have to refrain from
>> overriding it.
> 
> They would get it by default from our setup scripts. If they then 
> choose to turn it off, so be it.

If you're relying on setup scripts, you can

git config alias.pull 'pull --ff-only'

> 
>>> My idea was to add something like merge.options and pull.options
>>> as configuration options (I want to be able to specify the options
>>> separately for pull and merge). However, I wanted throw this out
>>> here first before starting to hack away at the code, in case I
>>> missed something obvious, or if others find this to be an
>>> incredibly stupid idea...
>>
>> In general, you can't control reliably what people do in their repos.
> 
> I sure wish I had more control over it, but that is a separate 
> discussion. ;)
> 
>> But you can control what kind of pushes into a central repo you allow.
>> That is the usual approach: Let them mess up their repos, they'll learn
>> their lesson when they can't push ;)
> 
> Can you differentiate between an automatic merge which happened
> because the user had made some local changes before pulling (which
> I do not want to appear in the central repo), and a real merge of 
> a topic branch (which I do want)?

I can't, and neither can Git. Who can?

I think this boils down to having a few people who are allowed to push
merges because they can make these decisions. Even if people don't merge
"origin" but their own branches they can create a mess, so you cannot
differentiate based on that.

Michael