On Fri, Oct 02, 2009 at 04:01:34AM -0400, Jeff King wrote: > > 0 files changed, 0 insertions(+), 0 deletions(-) > > mode change 100644 => 100755 t/t5531-deep-submodule-push.sh > > mode change 100644 => 100755 t/t9501-gitweb-standalone-http-status.sh > > > > diff --git a/t/t5531-deep-submodule-push.sh b/t/t5531-deep-submodule-push.sh > > old mode 100644 > > new mode 100755 > > diff --git a/t/t9501-gitweb-standalone-http-status.sh > > b/t/t9501-gitweb-standalone-http-status.sh > > old mode 100644 > > new mode 100755 > > When applying via "am", I only got the first change in my tree. I'll see > if I can confirm and make a test case. Ah, nevermind. The problem is that your patch was word-wrapped, making the second "diff --git" line bogus. It would have been nice to have it print a warning instead of silently ignoring that bit of the patch. I'm not sure if it is a good idea, though. git-apply sees that the "diff --git" line is there but can't get a filename from it. Which _should_ cause it to barf when we get to the mode lines. But we first see the wrapped filename and consider that patch section to be over (and the mode lines just become cruft at the end of the patch, which we must ignore). And we must consider that patch section to be over when we see random text, because we need to jump back to the outer parser looking for more hunks. We could warn about a "diff --git" line that has no actual changes associated with it, though that is certainly a user-visible change. I also suspect it wouldn't help if there was a mode change followed by some actual content changes. Hmph. -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