Re: [PATCH Hurd]: adding a missing comment

[Sergey Bugaev]

On Fri, Oct 25, 2024 at 9:50 AM Samuel Thibault <samuel.thibault@gnu.org> wrote:
> Zhaoming Luo, le ven. 25 oct. 2024 10:43:29 +0800, a ecrit:
> > it seems a bit unreliable (last commit is 7 months ago).
>
> Last commit not being that recent does not mean it's unreliable: it
> possibly just works and doesn't need updates.

This reminded me of
https://www.theolognion.com/p/npm-now-marks-packages-as-abandoned-after-24h-since-the-last-commit
🙃

(That's satire, of course.)

On Fri, Oct 25, 2024 at 5:49 AM Zhaoming Luo <zhaoming1357@qq.com> wrote:
>
> On 11/10/24 12:30 AM, Joshua Branson wrote:
> > Zhaoming, if you have never used git send-email, then I recommend it!
> >
> > This is a short guide that will walk you through how to use it.
> >
> > https://git-send-email.io/
> Thank you Joshua, I have tried it and it is very useful, I didn't
> realized this tool.

It's actually... not most convenient, but mostly easy, once you're
past the stage of setting it up to work with your email provider. I'm
in no way an authority or an expert, but here are my few tips:

To post a one-off patch to this list, you can just do

$ git send-email -1 --to=bug-hurd@gnu.org

Where '-1' means sending the current (latest) commit; you can do more
than 1 of course. You can do multiple --to's, if you want to send the
patch to multiple lists (e.g. both to libc-alpha and bug-hurd, for
glibc patches), as well as --cc to cc specific people. It's a good
idea to cc the people who wrote / last changed the part of code you're
changing.

If you add --rfc, the generated subject line will have [RFC PATCH]
instead of [PATCH], which is roughly analogous to WIP MRs on GitLab or
Draft PRs on GitHub, meaning you want to gather feedback, but don't
expect the patches to merged as-is. If you post a modified version
(aka a re-roll) of your patch (set), add -v2 (or -v3, -v4 etc), which
will result in e.g. [PATCH v2].

When posting a larger patch series, you might want to generate the
patches and send them in two distinct steps. For this, you can use git
format-patch (with pretty much all the same options); that will
generate a bunch of text files in your cwd that you can edit with your
favorite text editor; then you pass the patch files to git send-email
(e.g. 'git send-email *.patch') to actually mail them. It's oftentimes
a good idea to give an overview of a patch series; for this you use
--cover-letter, which will generate a dummy patch number 0, which you
can then write your description over.

> > I personally really like using Emacs' magit mode.  It makes messing
> > around with git things super easy!  Re-order commits, easily reword
> > commit messages, commit a change to an old commit that I made, combine
> > commits, etc.  In my humble opinion, it's one of the easiest ways to
> > work with git.
> >
> I have watched the demo of Magit. It's so attractive but I have used vim
> for three years. I found an alternative for vim which is called vimagit
> but it seems a bit unreliable (last commit is 7 months ago). I think I
> will starting changing to emacs.

Not to discourage you from using Emacs :), but my vim-using friend is
very happy with vim-fugitive, and from what I've seen of his workflow,
it does look/work a lot like Magit. From my personal experience, Magit
is easily one of the best things about Emacs, it might indeed be
superior to command-line Git (which is a very high bar for any Git
UIs, despite all the widely recognized issues with git CLI).

Sergey