[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMuHMdXaf_wfmwpQ4O5v+n8vd4uwddDANyZna4ufK10JxZhSvA@mail.gmail.com>
Date: Tue, 12 Mar 2013 18:51:44 +0100
From: Geert Uytterhoeven <geert@...ux-m68k.org>
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>,
Junio C Hamano <gitster@...ox.com>
Subject: Re: linux-next: unneeded merge in the security tree
On Tue, Mar 12, 2013 at 6:13 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>> Why not just force the head of the security tree to be v3.9-rc2? Then
>> you don't end up creating a completely unnecessary merge commit, and
>> users who were at the previous head of the security tree will
>> experience a fast forward when they pull your new head.
>
> So I think that may *technically* be the right solution, but it's a
> rather annoying UI issue, partly because you can't just do it in a
> single operation (you can't do a pull of the tag to both fetch and
> fast-forward it), but partly because "git reset --hard" is also an
> operation that can lose history, so it's something that people should
> be nervous about, and shouldn't use as some kind of standard "let's
> just fast-forward to Linus' tree" thing.
In many cases, "git rebase x" does the exact same thing as
"git reset --hard x", with an added safeguard: if you forgot to upstream
something, it'll boil up on top of "x".
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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