All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Alejandro Colomar <alx.manpages@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Better suggestions when git-am(1) fails
Date: Fri, 10 Mar 2023 08:28:55 -0800	[thread overview]
Message-ID: <xmqqh6us7epk.fsf@gitster.g> (raw)
In-Reply-To: <ZAr6vIOe3WbTIohE@coredump.intra.peff.net> (Jeff King's message of "Fri, 10 Mar 2023 04:39:08 -0500")

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.

>   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.

> 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.




  reply	other threads:[~2023-03-10 16:32 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08 20:15 Better suggestions when git-am(1) fails Alejandro Colomar
2023-03-09  3:17 ` Jeff King
2023-03-09  6:06   ` Jeff King
2023-03-09  6:07     ` [PATCH 1/5] diff: factor out src/dst prefix setup Jeff King
2023-03-09 10:50       ` Alejandro Colomar
2023-03-09  6:07     ` [PATCH 2/5] t4013: add tests for diff prefix options Jeff King
2023-03-09  6:09     ` [PATCH 3/5] diff: add --default-prefix option Jeff King
2023-03-09 10:51       ` Alejandro Colomar
2023-03-09 16:31       ` Junio C Hamano
2023-03-10  9:44         ` Jeff King
2023-03-10 17:04           ` Junio C Hamano
2023-03-13 16:43             ` Jeff King
2023-03-13 17:17               ` Junio C Hamano
2023-03-13 17:31               ` Junio C Hamano
2023-03-13 19:54                 ` Jeff King
2023-03-09  6:11     ` [PATCH 4/5] format-patch: do not respect diff.noprefix Jeff King
2023-03-09 10:53       ` Alejandro Colomar
2023-03-09 16:41       ` Junio C Hamano
2023-03-10  9:49         ` Jeff King
2023-03-09  6:12     ` [PATCH 5/5] format-patch: add format.noprefix option Jeff King
2023-03-09 17:00       ` Junio C Hamano
2023-03-10  9:51         ` Jeff King
2023-03-09 10:58     ` Better suggestions when git-am(1) fails Alejandro Colomar
2023-03-09 21:53     ` Junio C Hamano
2023-03-10  9:54       ` Jeff King
2023-03-09 16:22   ` Junio C Hamano
2023-03-10  9:39     ` Jeff King
2023-03-10 16:28       ` Junio C Hamano [this message]
2023-03-13 16:37         ` Jeff King
2023-03-13 17:10           ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqh6us7epk.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=alx.manpages@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.