RE: Use "git pull --ff-only" by default?
From: Peter Kjellerstedt <hidden>
Date: 2016-06-15 22:48:50
-----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:quoted
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.
quoted
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)?
Michael
//Peter