From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751989AbcG1WHM (ORCPT ); Thu, 28 Jul 2016 18:07:12 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:60140 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751438AbcG1WHH (ORCPT ); Thu, 28 Jul 2016 18:07:07 -0400 Message-ID: <1469743620.2324.20.camel@HansenPartnership.com> Subject: Re: [GIT PULL] configfs updates for 4.8 From: James Bottomley To: Linus Torvalds , Al Viro Cc: Christoph Hellwig , linux-fsdevel , Linux Kernel Mailing List Date: Thu, 28 Jul 2016 18:07:00 -0400 In-Reply-To: References: <20160728133032.GA11941@infradead.org> <20160728201846.GW2356@ZenIV.linux.org.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2016-07-28 at 13:24 -0700, Linus Torvalds wrote: > On Thu, Jul 28, 2016 at 1:18 PM, Al Viro > wrote: > > > > FWIW, git request-pull is very likely to make complete mess of > > diffstat - all it takes is branch started at -rc1, then a merge > > from > > anything started at later point (e.g. Miklos asking to pull > > ->d_real() > > work from his tree into vfs.git, with his branch starting at -rc5). > > Yes. git request-pull doesn't do a real merge, and if you have > multiple merge bases, the diffstat is usually garbage (because you > also end up getting diffs that are all about the differences in merge > bases, not the branch itself). Just in case it helps, this is what I do: I keep a static base around for each tree. Its the commit for which git log base...HEAD only returns the commits I've pulled or committed myself. I think mathematically, if you do a pairwise comparison of all the trees you've pulled, it ends up being the latest (tree relative) foreign commit that doesn't appear in any other tree you've pulled. if you can't be bothered to calculate it, then you can always merge up to some point in Linus' head beyond yours and that then becomes your base. I store it in a xxx-base branch for the xxx tree and then do git diff --stat -M --summary xxx-base...xxx James > So people who have more complex git history are certainly encouraged > to > > (a) do their own test-merge anyway, just to see that everything is > fine, and to be able to report to me about merge conflicts > > (b) use the result of that test-merge to generate a better diff-stat > than git request-pull does. > > So yes, people who have more complex git trees are very much welcome > to improve on git request-pull output. It's aoppreciated. > > What is *not* appreciated is when people send something worse ;) > > git request-pull tends to do really well for simple and > straightforward git users, which is what it's geared towards. If you > have linear history and don't do back-merges (which you shouldn't do > unless you really really know what you are doing anyway), you'll > never see the limitations of the stupid "just diff against the merge > base" approach. > > Linus