> -----Original Message----- > From: git-owner@xxxxxxxxxxxxxxx [mailto:git-owner@xxxxxxxxxxxxxxx] On > Behalf Of Michael J Gruber > Sent: den 21 maj 2010 15:49 > To: Peter Kjellerstedt > Cc: git@xxxxxxxxxxxxxxx > 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. > > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html