Re: [GIT PULL] configfs updates for 4.8

[James Bottomley]

On Thu, 2016-07-28 at 13:24 -0700, Linus Torvalds wrote:
> On Thu, Jul 28, 2016 at 1:18 PM, Al Viro <viro@xxxxxxxxxxxxxxxxxx>
> 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