On Fri, Jan 30, 2026 at 03:38:40PM -0500, Joe Lawrence wrote: > On Fri, Jan 30, 2026 at 12:05:35PM -0800, Josh Poimboeuf wrote: > > Hm, isn't the whole point of --recount that it ignores the line numbers? > > Or does it just ignore the numbers after the commas (the counts)? > > > > I don't know exactly. As I continue digging into the test that sent me > down this path, I just found that `git apply --recount` doesn't like > some output generated by `combinediff -q --combine` even with NO line > drift... then if I manually added in corresponding diff command lines > (to make it look more like a .patch file generated by `diff -Nu`), ie: > > diff -Nu src.orig/fs/proc/array.c src/fs/proc/array.c <--- > --- src.orig/fs/proc/array.c > +++ src/fs/proc/array.c > > Suddenly `git apply --recount` is happy with the patch. > > So I suspect that I started with git not liking the hunks generated by > combinediff and drove it to the rebase feature, which solves a more > interesting problem, but by side effect smoothed over this format > issue when it recreated the patch with git. > > Anyway, I think this patch still stands on it's own: perform the same > apply/revert check as what would happen in the fixup steps to fail > faster for the user?
If we just run fix_patches() at the beginning then can we just get rid of validate_patches() altogether? -- Josh
