Hi Jon,
> Which failure mode? I missed the description of a failure
> anywhere in this discussion. Is there a repeatable bug setup
> that duplicates this failure?
Yes indeed, it seems you missed the description, although I clearly
cited it now multiple times:
>> This option you used to make the patches smaller (find-copies or
>> something like this) really makes reviewing not easy. And
>> additionally the patch doesn't apply anymore, since the reference
^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> (sequoia) has changed in my non publiched branch already. Another
>> reason why I would like to see a 100k size limit on this list.
> Are you just referring to it not finding copies in patches
> by default? And that in this case someone used them to make the patch
> smaller? I mean, if it says 100% copy, then
> it is a literal move, and if it is fractional, the relevant
> diffs should be present in the patch still anyway.
No, I was talking about a diff based on the "copy and change" variant
not working anymore after the origin of the copy is changed _in the
repository where git-apply is attempted_.
> Right. As long as the SHA1 in the patch are present in
> the repository to which the patch is being applied, it will
> attempt to revert to a 3-way merge based on that ancestor.
Exactly, this was my original point. I obviously failed to make it
clear that git-apply or git-am alone will fail under the above
conditions.
>> For the git savvy among the readers on a lower level this uses
>> "--build-fake-ancestor" from git-apply although this option does not
>> lend itself to easy usage from a command line.
>
> Uh, "-3" on a "git am" command is pretty easy, isn't it? :-)
Did I say anything different? It was just an interesting piece of
information that I discovered in the process that I didn't want to keep
for myself.
> Which might be a subtle way of saying that I missed
> your point, perhaps?
So it seems.
Cheers
Detlev
--
I just found out that the brain is like a computer.
If that's true, then there really aren't any stupid people.
Just people running Windows.
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
