Hi Eric,
Today's linux-next merge of the audit tree got conflicts in
arch/mips/include/asm/syscall.h, arch/x86/Kconfig and kernel/audit.c
between commits from Linus' tree and commit 596b0569084b ("Merge tag
'v3.14' into mergeing") from the audit tree.
This happened because you merged Linus' tag v3.14 into your tree. In
this case, that merge had conflicts that you resolved differently to the
way Linus had resolved them when he merged your tree for v3.15-rc1. I
fixed it up (by using Linus' version) and can carry the fix as necessary
(no action is required).
You could have avoided this by doing a fast forward merge of v3.15-rc1
instead of the v3.14 merge (since everything in your tree before that
merge was also in Linus' tree by v3.15-rc1).
--
Cheers,
Stephen Rothwell [email protected]
On Wed, 2014-04-16 at 14:02 +1000, Stephen Rothwell wrote:
> You could have avoided this by doing a fast forward merge of v3.15-rc1
> instead of the v3.14 merge (since everything in your tree before that
> merge was also in Linus' tree by v3.15-rc1).
This is a situation I've never really known the right way to handle. I
certainly could/can fast forward to 3.15-rc1, but then I have a random
crap development base for the audit tree. Which is especially bad sine
-rc1 doesn't even boot on my main machine.
What I've always done is to merge the last release right after the pull
and go from there, but it clearly leaves conflict potential
Which is preferred? I've always enjoyed having my trees based on a
release....