Re: [PATCH gitk] gitk: add README.md with contribution guidelines

From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Aug 20, 2025, 23:42 UTC
Message-ID: <CALnO6CBznUApKLv2pQbX9QJBU=O6R3MTo42AePp0kp2X-x3Vag@mail.gmail.com>
In-Reply-To: <CANoM8SX7_uQV-ZRAim55UaiHYCKTgKN0AO6zB1O7Ux4deiCNaw@mail.gmail.com>

On Wed, Aug 20, 2025 at 5:20 PM Mike Rappazzo <rappazzo@gmail.com> wrote:

Show 38 quoted lines

>
> On Wed, Aug 20, 2025 at 5:12 PM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Mike Rappazzo <rappazzo@gmail.com> writes:
> >
> > > On Wed, Aug 20, 2025 at 4:57 PM Junio C Hamano <gitster@pobox.com> wrote:
> > >>
> > >> Michael Rappazzo <rappazzo@gmail.com> writes:
> > >>
> > >> > +#### Creating and Sending Patches
> > >> > +After committing your changes:
> > >> > +```bash
> > >> > +git format-patch -1 --subject-prefix="PATCH gitk"
> > >> > +git send-email --to=git@vger.kernel.org --cc=j6t@kdbg.org *.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