On Wed, Aug 20, 2025 at 5:20 PM Mike Rappazzo <rappazzo@xxxxxxxxx> wrote:
>
> On Wed, Aug 20, 2025 at 5:12 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> >
> > Mike Rappazzo <rappazzo@xxxxxxxxx> writes:
> >
> > > On Wed, Aug 20, 2025 at 4:57 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
> > >>
> > >> Michael Rappazzo <rappazzo@xxxxxxxxx> writes:
> > >>
> > >> > +#### Creating and Sending Patches
> > >> > +After committing your changes:
> > >> > +```bash
> > >> > +git format-patch -1 --subject-prefix="PATCH gitk"
> > >> > +git send-email --to=git@xxxxxxxxxxxxxxx --cc=j6t@xxxxxxxx *.patch
> > >> > +```
> > >>
> > >> Just being curious, but does the project strongly discourage a
> > >> multi-patch topic?
> > >
> > > I don't believe so. I think most people know how to submit a github
> > > PR, but J6t has mentioned that he prefers the mailing list (as noted
> > > in the readme). So I wrote a simple example to show that patching by
> > > email doesn't have to be scary.
> >
> > As the original assumes that you are on the branch where you are
> > taking the patch(es) from, perhaps
> >
> > $ git format-patch --subject-prefix='PATCH gitk' @{u}..
> >
> > would work? I was mostly reacting to the "-1" on the command line.
>
> `@{u}..` is funny, because that seems to assume that you haven't
> pushed your changes to its upstream yet. I could say `master..` but
> that assumes that you named the branch that (as opposed to `main` or
> something). I will try a few different ways and see how they feel.
> As I said, I just wanted an example to demystify patching by email. I
> think if I add something above to clarify that this is just an example
> and not verbose instructions it could help too.
It is less funny when @{u} is the branch you started your work from
and where you hope to integrate to, as in
git switch -c topic origin/master
or something.
Then, you might use @{push} to refer to that "somewhere else" you push
to that is not the place to which you hope your changes will go. It is
certainly different from lots of GitHub- and similar tutorials that
encourage "git push -u <remote> <branch>," which sets @{upstream} to
what I prefer to use @{push} for. Granted, those tutorials use
something closer to a centralized workflow, and what I'm describing
(what mailing list flows are?) is more triangular.
> > >> It would be really nice if you add "review them here before you run
> > >> send-email" step between these two commands ;-).
> > >
> > > I can revise. I will wait for more comments before sending a v2.
Linking to https://git-send-email.io/ is probably the best advice on
making sending patches less scary.
--
D. Ben Knoble
