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

-----Original Message-----
From: Michael J Gruber [mailto:git@drmicha.warpmail.net]
Sent: den 21 maj 2010 17:18
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 16:47:

quoted

quoted

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

If you're relying on setup scripts, you can

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

I forgot to mention that I had tried that. It does not work as git 
explicitly does not allow one to use a git command name as an alias 
name. And I think this is a good policy since it prevents people 
from aliasing plumbing commands to do weird things. However, I would
like to see some way to affect the defaults of porcelain commands.

quoted

quoted

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. ;)

quoted

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?

Exactly. Which is why I would like for --ff-only to be the default
as I think that is more sane in an environment where most of the
users are git newbies.

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.

In a larger organization this does not work. Most of our developers
are responsible for at least one subsystem and expected to be the one 
responsible for its master branch. We cannot rely on a few git veterans 
to be the only ones with merging rights; it would never be accepted by 
the management...

Michael

//Peter