linux-kernel - Re: [GIT PULL] configfs updates for 4.8

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Jul 2016 18:07:00 -0400
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Al Viro <viro@...iv.linux.org.uk>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] configfs updates for 4.8

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