linux-kernel - Re: nfsd changes for 2.6.39

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] [day] [month] [year] [list]

Message-ID: <AANLkTi=cWJYCt1-vwNndzK_beU_Z7gZ0uvsLj4msAxa=@mail.gmail.com>
Date:	Thu, 24 Mar 2011 08:20:07 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"J. Bruce Fields" <bfields@...ldses.org>
Cc:	linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: nfsd changes for 2.6.39

On Wed, Mar 23, 2011 at 8:58 PM, J. Bruce Fields <bfields@...ldses.org> wrote:
>
> The diffstat generated by request-pull looked horribly wrong despite the
> individual patches looking reasonable; I assumed it was a side effect of
> the one back-merge and didn't look any closer.  Sorry, I probably should
> have looked closer or asked for help.
>
> Here you go--did I screw something up?

Yeah - the back merge. One of the bad side effects is that now you
don't have a nice clear merge base any more, but _multiple_ merge
bases (think "you  mixed up your development tree with the upstream
development tree").

Now, most of the time you end up being lucky, and when git picks one
of those merge bases and tries to diff against them, it all works out
anyway, and you get a reasonable diff. But not always. Because in the
case of multiple merge bases, the only _real_ way to get a proper diff
is actually to do the merge (and let merge sort out all the
complexities) and then do the diff of the result.

But no, you didn't screw up as in "the diff is wrong" - it's just that
the diff isn't rally valid, because git tried to do a diff against the
merge base, but with multiple too choose between it just sometimes
screws up.

One more reason to try to avoid mixing development streams.

(People who do this a lot have learnt to do a private merge into a
temporary branch, and do the diff against that. I don't want to see
that merge though - just think of it as a temporary throw-away thing
just for the diff).

I'll pull.

            Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/