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

On Mon, May 24, 2010 at 10:22:45AM +0200, Peter Kjellerstedt wrote:

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.

Though, some porcelain commands (such as "branch") should never be used
in scripts, many others do not have low-level analogue, so they are
commonly used in scripts.

quoted

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.

Right. Now, if only one person who is responsible for this subsystem is
expected to be able to push changes to the master branch then this
person will never need "git pull --ff-only". In fact, when he pulls
changes from others, he needs a real merge. So, this alone a very strong
argument against making ff-only by default in any configuration.

And if you think that "pull --ff-only" is very useful for some reason,
nobody prevents to add an alias for that command, but this command
should never be called as "pull", because "pull" has always been about
merging changes, and if it does something different, you should call it
differently. Why don't call it as "fast-forward" or "ff" for short?


Dmitry