Okay, I figured it out. using the --stdout param to format-patch was the issue. the generated patch file can't even be applied with the windows github desktop version of git that created the patch.
using normal format-patch makes a patch file with the correct line endings. Running the --stdout patch through dos2unix also worked as a workaround. Thanks for the pointer towards line endings. Not sure if this is an edge case that's worth looking for. On Thu, Jul 6, 2017 at 10:51 PM, Sean Busbey <[email protected]> wrote: > checking the relevant files in the repo shows that they have the correct > line endings. > > the gitattributes wouldn't apply to the output of git diff or format-patch > itself. > > lemme see if changing the line endings of the patch helps. > > On Thu, Jul 6, 2017 at 7:41 PM, Allen Wittenauer <[email protected] > > wrote: > >> >> > On Jul 6, 2017, at 4:35 PM, Allen Wittenauer <[email protected]> >> wrote: >> > >> > >> >> On Jul 6, 2017, at 3:42 PM, Sean Busbey <[email protected]> wrote: >> >> >> >> The patches are all generated on windows, using the git that comes >> from the >> >> github desktop application. I'm at a loss; the patches all look fine >> when I >> >> open them in an editor. >> > >> > >> > "HBASE-18327.1.patch" [converted][dos] >> > >> > It's gotta be a character conversion problem. >> >> I don't think the desktop app is honoring .gitattributes ... >> >> ---snip-- >> # Declare files that will always have LF >> *.sh text eol=lf >> --snip-- >> >> ... which is likely confusing git commands that do. >> >> >
