On 03/23/2012 05:15 AM, Linus Torvalds wrote: > On Thu, Mar 22, 2012 at 5:10 PM, Benjamin Herrenschmidt > <benh@xxxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
