Re: Better suggestions when git-am(1) fails
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 10, 2023, 16:28 UTC
- Message-ID
- <xmqqh6us7epk.fsf@gitster.g>
- In-Reply-To
- <ZAr6vIOe3WbTIohE@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 1. I feel like "-p1" was pretty standard even before Git. You'd > extract two copies of the tarball, one into "foo-1.2.3" and one > into "foo-1.2.3.orig", and then "diff -Nru" between them to send a > patch.
I would too, but then we wouldn't have accepted the request to add .noprefix configuration; I do not recall where it came from.
Show 7 quoted lines
> 2. It feels weird that a maintainer who isn't using Git would expect a > lot of contributions from folks who are. And even weirder, that > they would insist that all of the folks sending patches set > diff.noprefix. > > So I won't say it's not possible (especially in some closed community). > But I'm skeptical.
The scenario I would find more likely is a project established long before we were popular wants to keep using -p0 even after switching to use Git.
> All that said, if "apply" and "am" could automatically figure out > and handle "-p0" patches, that would be a useful way to help > people. I'm just hesitant because it probably involves some heuristics.
I am not all that interested in that direction, for exactly the same reason as I are heditant. Such a tool that outsmarts users will eventually bite them.
Show 6 quoted lines
> Yeah, I am as always a little concerned that one person's fix is another > one's regression. But it really just seems to that on balance people set > diff.noprefix with no thought at all to how it would affect format-patch > (in fact, I'd guess 99% of Git users do not use format-patch at all). > And then they are surprised (or worse, the receiver is surprised) when > it doesn't work.
For these 99% users, if format-patch paid attention to their diff.noprefix and used -p0, the world would become even more interesting place. I am not sure this particular cure is an overall win. And as you mentioned elsewhere, a change that is deliberately designed to be breaking like this does not become much safer by cooking in 'next', which is another sad thing.