Re: [GIT PULL] KVM updates for the 3.4 merge window

[Avi Kivity <avi@redhat.com>]

On 03/23/2012 05:15 AM, Linus Torvalds wrote:
> On Thu, Mar 22, 2012 at 5:10 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >
> > That means that everything gets constantly rebased, and it makes life
> > very much harder for us working with this.
>
> Ben, thanks for pointing this out.
>
> I will not be pulling this tree at all. It's pure and utter shit, and
> I wonder how long (forever?) this has been going on.
>
> The particular issue that upsets *me* is only indirectly the problem
> Ben is mentioning. No, the thing that makes me go "uhhuh, no way in
> *hell* should I pull this" is that you have apparently totally broken
> all sign-offs.
>
> Avi, you ABSOLUTELY MUST NOT rebase other peoples commits. That's a
> total no-no. And one thing I notice when I look through the commits is
> that you have totally broken the Signed-off-by: series in the process,
> exactly because what you do is crap, crap, CRAP.
>
> The sign-off chain should be very simple: the first person to sign off
> should be the author, and the last person to sign off should be the
> committer.
>
> That's simply not true in your tree. Maybe because you have rebased
> other peoples (Alexander's) commits? I see commits where the sign-off
> ends with Alexander, but then the committer is you. WTF?
>
> Fix your f*cking broken shit *now*.
>
> I'm not pulling crap like this. And it makes me unhappy to realize
> that this has probably happened a long time and I haven't even
> noticed.
>
> The whole "you MUST NOT rebase other peoples commits" is the thing
> I've been telling people for *years* now. Why the hell is it still
> going on?

Well I've been doing this ever since I moved to git.  The motivation was
actually to make things easier for patch authors by allowing them to
work against a tree of all applied patches, while the update for the
next merge window is just a subset, with more fixes going into the merge
window even late in the cycle, and features being deferred to the next
one.  I also fold fixes or reverts into their parent patches to improve
bisectability.

I can switch to fast-forward-only in the future, but I'm afraid that
this particular tree is broken for good.  The un-rebased
fast-forward-only source for this is kvm.git master, which I don't think
you want to pull.  It will cause every kvm commit to appear twice and
confuse everyone.

-- 
error compiling committee.c: too many arguments to function