From: Jon Loeliger <jdl@freescale.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [PATCH] Fix return value of mtest when CFG_ALT_MEMTEST set
Date: Fri, 15 Feb 2008 14:26:23 -0600 [thread overview]
Message-ID: <47B5F56F.5020407@freescale.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0802152101460.19124@axis700.grange>
Guennadi Liakhovetski wrote:
> On Thu, 14 Feb 2008, Wolfgang Denk wrote:
>
>> In message <Pine.LNX.4.64.0802131116340.5484@axis700.grange> you wrote:
>>> Fix a missing return statement from a non-void function.
>>>
>>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
>> Applied, thanks.
>>
>> Ummm... I had to apply this manually:
>>
>> error: patch failed: common/cmd_mem.c:695
>> error: common/cmd_mem.c: patch does not apply
>> fatal: sha1 information is lacking or useless (common/cmd_mem.c).
>> Repository lacks necessary blobs to fall back on 3-way merge.
>> Cannot fall back to three-way merge.
>> Patch failed at 0001.
>>
>> How old is your source tree?
>
> I produced the patch against 1.2.0, but before that I've verified, that
> the file, or at least the affected function hasn't changed, so, thought it
> would be ok. Sorry. But what does the error message actually mean? Is it
> just because I referenced some "way too old" commit?
>
No. "Way too old" is not the issue with the error message.
First off, the patch didn't apply directly to the file.
That's our key that the patch isn't up-to-date with the
current tree, as that file has changed significantly enough
that your changes are no longer applicable.
In that situation, git tries to do a clever trick by backing
off to a common ancestor where the patch was originally created.
That is the first SHA1 in the diff header, assuming the patch
was generated by git. If it can find this commit, git knows that
the patch will apply at that point as that is what your presumably
started with for your patch creation. Git will apply the patch
there, and try to follow the changes forward in an attempt to
bring the changes up to date itself.
However, in this case, the SHA1 was only in your repository, and
not a common commit that was also in the public repository. Thus,
git couldn't fall back on the three-way merge trick, and ultimately
was not able to apply your patch.
The remedy is to rebase your patch to a current repository and
resubmit it! :-) Chance are it will require some conflict resolution.
jdl
next prev parent reply other threads:[~2008-02-15 20:26 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-13 10:19 [U-Boot-Users] [PATCH] Fix return value of mtest when CFG_ALT_MEMTEST set Guennadi Liakhovetski
2008-02-14 22:37 ` Wolfgang Denk
2008-02-15 20:03 ` Guennadi Liakhovetski
2008-02-15 20:26 ` Jon Loeliger [this message]
2008-02-15 20:45 ` Guennadi Liakhovetski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47B5F56F.5020407@freescale.com \
--to=jdl@freescale.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.