Linus Torvalds [off-list ref] writes:
One is simple:
git config alias.sync="pull --ff-only"
Heh, I just wrote that myself after reading the early part of this
message ;-)
which works fine, but forces submaintainers to be careful when doing
things like this, and using a special command to do back-merges.
And maybe that's the right thing to do? Back-merges *are* special,
Yes.
after all. But the above alias is particularly fragile, in that
there's both "pull" and "merge" that people want to use this for, and
it doesn't really handle both. And --ff-only will obviously fail if
you actually have some work in your tree, and want to do a real merge,
so then you have to do that differently. So I'm mentioning this as a
better model than "git reset", but not really a *solution*.
That said, the fact that "--ff-only" errors out if you have local
development may actually be a big bonus - because you really shouldn't
do merges at all if you have local development, but syncing up to my
tree if you don't have it (and are going to start it) may be something
reasonable.
Yes, that's the reasoning behind all the behaviours you described
above.
Now, the other approach - and perhaps preferable, but requiring actual
changes to git itself - is to do the non-fast-forward merge *only* for
FETCH_HEAD, which already has magic semantics in other ways. So if
somebody does
git fetch linus
git merge v3.8
to sync with me, they would *not* get a merge commit with a signature,
just a fast-forward. But if you do
git pull linus v3.8
or a
git fetch linus v3.8
git merge FETCH_HEAD
it would look like a "maintainer merge"....
I am not sure I follow. Are you solving the real problem, the
pointeless merge in the "security tree" that started this thread?
I would imagine it was made by somebody thinking that pulling a
tagged stable point from you is a good idea, like this:
git pull linus v3.9-rc2
which under your FETCH_HEAD rule would look like a maintainer merge,
no?
An alternative may be to activate the magic "mergetag" thing only
when you give "--no-ff" explicitly; otherwise merge would unwrap the
tag, whether it comes from FETCH_HEAD.
The following examples all assume that your HEAD is somewhere
behind v3.9-rc2, perhaps done by
git checkout -b test v3.8^0
Then under the "--no-ff activates the magic" rule:
git merge v3.9-rc2
will fast-forward, but this
git merge --no-ff v3.9-rc2
creates a real merge with the "mergetag" signature block. The one
that caused trouble in the "security tree", i.e.
git pull linus v3.9-rc2
or its equivalent
git fetch linus v3.9-rc2
git merge FETCH_HEAD
would still fast-forward under this rule. The maintainer needs to
do
git pull --no-ff git://git.kernel.org/... for-linus
if the pull could fast-forward under this rule, though.
Having thought this up to this point, I am not sure it generally is
a good change. It feels that "pull --ff-only" that prevents people
from creating pointless back-merges may still be a better mechanism.
I dunno.