Re: linux-next: unneeded merge in the security tree

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 12, 2013, 19:49 UTC
Message-ID: <7vsj40760d.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CA+55aFzFLDcN-1GKae6Xqrns59K1xOD_HPzuv2Lv1__fZpqFMw@mail.gmail.com>

Linus Torvalds <torvalds@linux-foundation.org> 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.

Show 6 quoted lines

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

Show 5 quoted lines

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

Show 19 quoted lines

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