Re: Salvaging borked project history

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mason <slash.tmp@xxxxxxx> writes:

> But 'git am' just gave up. Small sample of errors:
>
> error: patch failed: drivers/block/Kconfig:411
> error: drivers/block/Kconfig: patch does not apply
> error: drivers/tty/serial/8250/8250.c: does not exist in index
> error: patch failed: drivers/tty/serial/8250/8250_early.c:121
> error: drivers/tty/serial/8250/8250_early.c: patch does not apply
> error: patch failed: drivers/video/Kconfig:101
> error: drivers/video/Kconfig: patch does not apply
> ...
> Patch failed at 0001 Commit for supporting Sigma Designs' SoCs.
> The copy of the patch that failed is found in:
>    .git/rebase-apply/patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this patch, run "git am --skip" instead.
> To restore the original branch and stop patching, run "git am --abort".
>
> How do I "resolve this problem".

You look at .git/rebase-apply/patch and drivers/block/Kconfig in
your editor, and edit the former to make it apply (i.e. adjust the
common context lines that begin with SP and preimage lines that
begin with '-' to match what you see in the drivers/block/Kconfig
where the change wants to go).  You do so for all the other files.

And then run "git am" again without any argument, until the patch
applies.

One way to "edit .git/rebase-apply/patch and make it apply" that is
often necessary when you are applying to codebase that is way more
ahead than where you took the original patches is to hand-edit the
working tree files (e.g. drivers/block/Kconfig) that the patch wants
to touch and change it in the way the patch wants to, while viewing
the original .git/rebase-apply/patch in your pager (you do not
directly edit this original patch---you only use it as a guide to
discern what the patch wants to do).  Once the working tree files
are in a state that the patch would have wanted to make if it were
taken based on the new codebase, overwrite .git/rebase-apply/patch
with the output from "git diff HEAD".  After that (i.e. you have
"edited" .git/rebase-apply/patch, with the help with your editor,
the working tree files and "git diff"), do "git reset --hard".

Which brings you to the same state just after "git am" gave up and
you correctly edited ".git/rebase-apply/patch:" to make it apply.

So you run "git am" again without any argument.  This time the patch
would apply and continue.

But I personally think "git am -3" may be easier to handle.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]