On Thu, Nov 17, 2011 at 09:43:02AM -0800, Junio C Hamano wrote: > I didn't mention this, but I suspect the code with your patch would not > touch redundant slashes after it finds "start", either. What is happening to me is that b//foo with -p1 gets split at the first slash and then git apply cannot find /foo when it should be looking for foo. But in the case of b/foo//bar and -p1, without squashing extra slashes it would look for foo//bar which I presume that it would still be able to find. So in my case, I only need duplicate slashes around the -p boundary point to be removed. I assumed that the squash_slash() later on would eliminate the rest, but I didn't look into this; if it does it'd be a different issue to the one that I'm seeing. I'm now confused about what it will do (which is why I need to look at it again to make sure), but if it turns out to be easier to just handle that one boundary point, would you accept a patch that eliminates just that duplicate, on the basis that in Unix-land duplicate slashes are perfectly acceptable to be left lying around? Thanks, Robie -- 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