On Fri, Jan 30, 2026 at 02:59:53PM -0800, Josh Poimboeuf wrote: > 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?
Or at least validate_patches() could be replaced with check_unsupported_patches(), as the apply/revert test wouldn't be needed since the actual apply/revert would happen immediately after that in fix_patches(). -- Josh
