Peter Kjellerstedt venit, vidit, dixit 21.05.2010 16:47: >> -----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. 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 -- 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