linux-kernel - Re: [GIT pull] irq core changes for 3.16

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: <CA+55aFxTLKJuWvUUvVEi4LssQEMzA_3nMR=_LYjv4ksmkRO-ZQ@mail.gmail.com>
Date:	Wed, 4 Jun 2014 16:12:50 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...nel.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [GIT pull] irq core changes for 3.16

On Wed, Jun 4, 2014 at 12:34 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
>
> Is what my script uses for years now, but this time it created a diff
> with random extra content from all over the tree.
>
> $BASE is 2ed9fd28c2884e9f41c133f86a7e377d7c0a96bf

You have criss-cross merges, so there are multiple merge-bases. You
can see if it you use the "--all" flag to "git merge-base". For
example, there's that "Merge branches 'linus' and 'irq/urgent' into
irq/core" that does a back-merge of my tree, and there's also a "Merge
tag 'irqchip-mvebu-3.16' of git://git.infradead.org/linux-mvebu into
irq/core" that merges stuff that is already in my tree. So there is
not a single unique shared base-point.

When that happens, doing the diff against one of the base points *can*
happen to work, but generally gives other random cruft from the other
shared part of the tree as part of the diff. It happened for your
timer core pull too, you just didn't notice because the shared part
was much smaller.

Anyway, for the "there are multiple different commits in common" case,
the only way to get a true diff is to generate the actual merge in a
temporary branch, and see what the result is (and then just throw away
the merge). The git merge facilities are much smarter than just
diffing between two points, and will actually recursively merge up the
different base points in order to generate the final merge result.

But if it's rare, it doesn't much matter if the trivial "let's just
diff against the base" doesn't always work. But this *is* one of the
reasons why I suggest against back-merges, because it makes the
history harder to figure out, and it causes these kinds of "there are
many different independent base points" issues.

                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/