On Thu, 12 Jul 2018 08:41:23 +0100
Ken Moffat <zarniwh...@ntlworld.com> wrote:

> And the generic command is probably 'git revert 7744ccdbc16f' but
> since I'm not currently bisecting, I'm not sure what state that
> would leave things in.


  Ken,

I should have realized that since Hazel was working with the full git tree,
that he could easily revert any commit within git. Duh!

Hmmmm ... I think what I was thinking was that I didn't trust the results
of the bisection within git (because the identified problem code does not
even seem be active within Hazel's config, and Hazel said he was new to
the bisection process). So, I'm not so sure the commit that is believed
to be the offender really is the guilty party. I was thinking that Hazel
would take the 4.15 source tree (from the official release tarball) and
then manually backout the suspect commit - if that works/boots, then it
is virtually certain we found the problem area (as we didn't depend on
git).

And, if we find the problem commit, the next step might be to manually
change things in the source until we home in on the offending *line*,
if possible. So, we'd be manually tweaking the source at some point
anyway.


With regard to reversing a patch (without any use of git), is it for
certain that the -R option of patch can be used to reverse *any*
patch file?

https://www.drupal.org/patch/reverse

If it is not universally possible to create a reverse patch using only
the information in a patch file, then I'd say that that is an oversight
in the design of diff.


There is a lot more info on the topic of reversing patches here:

https://stackoverflow.com/questions/3902388/permanently-reversing-a-patch-file


The interdiff utility and the patchutils package are new to me:

http://cyberelk.net/tim/software/patchutils/

( simple standard install: ./configure --prefix=/usr
                           configure looks for perl and xmlto )

Interdiff can create an "inverse" patch file via:

interdiff file.patch /dev/null > reversed.patch

The resulting reverse patch looks good to me, but when I tried a dry
run:

patch --dry-run -p1 -i 
../tip-x86-mm-x86-mm-Add-Secure-Memory-Encryption-SME-support_reverse.patch

I got:

checking file arch/x86/Kconfig
Reversed (or previously applied) patch detected!  Assume -R? [n]

I don't understand why it would think the patch had been already applied
as the patch is supposed to *delete* code that is indeed in my Kconfig file.
I think the problem might be because the specific kernel tree I tried it on
has the context lines at 1436 rather than the 1415 specified by the patch.

I've attached a copy of the interdiff created

tip-x86-mm-x86-mm-Add-Secure-Memory-Encryption-SME-support_reverse.patch

in case anyone wants to look at/try it.

Anyway, for the record, in the stackoverflow post, Lie Ryan's script
is not quite right. It reverses the --- and the +++ alright, but
later on it reverses the - and + at the start of the lines which also
ends up affecting the --- and +++ lines and so we end up getting -++
and +--. If he went through all that trouble to create that script,
didn't he take the time to inspect the results of it? Sigh.


  Cheers,

  Mike

Attachment: tip-x86-mm-x86-mm-Add-Secure-Memory-Encryption-SME-support_reverse.patch
Description: Binary data

-- 
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style

Reply via email to