Message-ID: <7vsj40760d.fsf@alter.siamese.dyndns.org>
Date:	Tue, 12 Mar 2013 12:49:38 -0700
From:	Junio C Hamano <gitster@...ox.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	"Theodore Ts'o" <tytso@....edu>, James Morris <jmorris@...ei.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Git Mailing List <git@...r.kernel.org>
Subject: Re: linux-next: unneeded merge in the security tree

Linus Torvalds <torvalds@...ux-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.

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists