On Sat, Dec 20, 2008 at 08:55:14AM +0100, Robin Rosenberg wrote:
> > Hmm. I wanted to try some performance comparisons based on this
> > implementation, but I can't get your 1/4 to apply. Conflicts in
> > config.txt and cache.h when applying to master, and "sha1 information is
> > lacking or useless" for a 3-way merge. What did you base this on?
>
> patch(1) however can crunch it, with the exception of cache.h. Shouldn't
> git am/appy and patch agree on git generated patches (without binary diffs)?
No. git apply is intentionally much more strict about applying under the
assumption that it is better to force a conflict than to silently apply
something that has a reasonable chance of being completely wrong.
And usually it is not a big deal because falling back to the 3-way merge
is a much nicer way of handling any conflicts _anyway_ (I find .rej
files so much more useless than conflict markers, personally).
In this case I was able to:
1. git am /the/patch
2. patch -p1 <.git/rebase-apply/patch
3. manually inspect the results for sanity, and fix up the cache.h
bit that failed totally
4. git add -u && git add notes.[ch]
5. git am --resolved
-Peff
--
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
