I use Gmail for email, Emacs (and sometimes vim) for editing, and Git
and command line tools, like make, gdb, etc, along with shell aliases
and functions, for building, debugging, sending patches to the mailing
list, etc.
Thunderbird is more like what I am looking for, which has a convenient
GUI with loaded batteries, while still being more configurable than Apple
Mail and actually handling threading properly. This is what I currently use,
but my laptop is unhappy with it, as it eats up around 40-50% of the CPU
usage in the background. It also eats up more battery, almost as much as
my browser. This is apparently a bug that’s been unresolved for many years
now. Git developers reading this: if you have personal recommendations
for something that is easy to use but also lightweight, please do let
me know! (and it needs to work on macOS)
That's bad. After a long time of switching, Thunderbird is what worked for
me too (after some config tweaks, of course). Evolution was close but it
had some bugs with the composition window. Otherwise Evolution was good,
light-weight and is well suited for plain-text emails. But looks like
it only works for Unix-like distributions[1]. So, its not an option for
you.
I don't own a Mac and haven't used one for personal use. So, I don't
have great recommendations. Anyways, light-weight reminds me of mutt[2].
But its likely one of the non-GUI clients that might also need a bit of
configuring.
In case you could consider alternative solutions for filtering e-mail,
there's the filtering option of Gmail[3] which could help. You could
filter emails based on certain criteria and send them to specific
folders[4] which could help you with managing emails to an extent.
I heavily rely on this feature to keep my Inbox clutter-free to
an extent.
[1]: https://en.wikipedia.org/wiki/Comparison_of_email_clients#General
[2]: http://www.mutt.org/
[3]: https://support.google.com/mail/answer/6579?hl=en
[4]: https://www.gtricks.com/gmail/organize-gmail-by-sending-emails-directly-to-a-folder-label/
I just use a straightforward { editor + MUA + git } stack and go with the flow!
For me it has mostly been this but with some help from tools. Many
people have found GitGitGadget[5] useful for sending patches to mailing
list based workflow from a GitHub PR like interface (Thanks to Dscho!)
You could've heard of it before but you could give it a try and
see if it helps improve things for you :-)
I've heard there's git send-series[6] which says that it helps
with managing patch series. I haven't used it myself, though.
These are some tools that come to mind. I believe others could
likely provide better insights.
[5]: https://gitgitgadget.github.io/
[6]: https://github.com/felipec/git-send-series
Have a great day!
Thanks! Hope you have a great week ahead!
On 26/07/21 11:15 pm, Shourya Shukla wrote:
It would have been nice to copy the survey on the email.
What tools, systems and workflows do you find valuable in your
day-to-day work? In particular I’d be happy getting insights like:
* Any strategy or approach to work, kind of like the example I quoted
above
* Any scripts and tools that assist you
* Opinionated handling of multiple in-flight series and methods to
approaching reviews
* Atharva, you are overthinking this! I just use a straightforward {
editor + MUA + git } stack and go with the flow!
Personally I use mbsync + notmuch + notmuch-vim + vim + msmtp. You can
watch an example session in asciinema.org [1].
This deals with the filtering issue that you talked about in your blog
post, for example one of the latest queries I ran is
"from:felipe subject:mergetool", plus there's tags so I can mark
messages with "inbox", "git", or "to-do".
Of course you can use emacs instead of vim, but I use vim.
Haveing all the feedback readily available helps me address it easily.
For me notmuch is like git for mail.
Cheers.
[1] https://asciinema.org/a/oo4yUOQDDF2CrWZbzhZURFtTW
--
Felipe Contreras
Thunderbird is more like what I am looking for, which has a convenient
GUI with loaded batteries, while still being more configurable than Apple
Mail and actually handling threading properly. This is what I
currently use,
but my laptop is unhappy with it, as it eats up around 40-50% of the CPU
usage in the background. It also eats up more battery, almost as much as
my browser. This is apparently a bug that’s been unresolved for many
years
now. Git developers reading this: if you have personal recommendations
for something that is easy to use but also lightweight, please do let
me know! (and it needs to work on macOS)
That's bad. After a long time of switching, Thunderbird is what worked for
me too (after some config tweaks, of course). Evolution was close but it
had some bugs with the composition window. Otherwise Evolution was good,
light-weight and is well suited for plain-text emails. But looks like
it only works for Unix-like distributions[1]. So, its not an option for
you.
I don't own a Mac and haven't used one for personal use. So, I don't
have great recommendations. Anyways, light-weight reminds me of mutt[2].
But its likely one of the non-GUI clients that might also need a bit of
configuring.
In case you could consider alternative solutions for filtering e-mail,
there's the filtering option of Gmail[3] which could help. You could
filter emails based on certain criteria and send them to specific
folders[4] which could help you with managing emails to an extent.
I heavily rely on this feature to keep my Inbox clutter-free to
an extent.
[1]: https://en.wikipedia.org/wiki/Comparison_of_email_clients#General
[2]: http://www.mutt.org/
[3]: https://support.google.com/mail/answer/6579?hl=en
[4]:
https://www.gtricks.com/gmail/organize-gmail-by-sending-emails-directly-to-a-folder-label/
Thanks for the information. I do use the filtering of Gmail, but I
remember back when I used a non-GUI client I had all sorts issues with
mapping the newly made Gmail directories with folders on my system. I
believe you have to configure one each time, which is fine when you
don't have to do it too, often but I had given up after the third time.
quoted
I just use a straightforward { editor + MUA + git } stack and go with
the flow!
For me it has mostly been this but with some help from tools. Many
people have found GitGitGadget[5] useful for sending patches to mailing
list based workflow from a GitHub PR like interface (Thanks to Dscho!)
You could've heard of it before but you could give it a try and
see if it helps improve things for you :-)
I appreciate the utility of GitGitGadget, and I thought I'd end up using
that when contributing, but I found email to be simpler and more
intuitive (at the time, it felt less intimidating to use).
I've heard there's git send-series[6] which says that it helps
with managing patch series. I haven't used it myself, though.
These are some tools that come to mind. I believe others could
likely provide better insights.
[5]: https://gitgitgadget.github.io/
[6]: https://github.com/felipec/git-send-series
It would have been nice to copy the survey on the email.
Okay. Thanks for quoting it here.
quoted
What tools, systems and workflows do you find valuable in your
day-to-day work? In particular I’d be happy getting insights like:
* Any strategy or approach to work, kind of like the example I quoted
above
* Any scripts and tools that assist you
* Opinionated handling of multiple in-flight series and methods to
approaching reviews
* Atharva, you are overthinking this! I just use a straightforward {
editor + MUA + git } stack and go with the flow!
Personally I use mbsync + notmuch + notmuch-vim + vim + msmtp. You can
watch an example session in asciinema.org [1].
Thanks for the visual demonstration!
This deals with the filtering issue that you talked about in your blog
post, for example one of the latest queries I ran is
"from:felipe subject:mergetool", plus there's tags so I can mark
messages with "inbox", "git", or "to-do".
Of course you can use emacs instead of vim, but I use vim.
Haveing all the feedback readily available helps me address it easily.
For me notmuch is like git for mail.
Cheers.
[1] https://asciinema.org/a/oo4yUOQDDF2CrWZbzhZURFtTW
What tools, systems and workflows do you find valuable in your
day-to-day work? In particular I’d be happy getting insights like:
* Any strategy or approach to work, kind of like the example I quoted
above
* Any scripts and tools that assist you
* Opinionated handling of multiple in-flight series and methods to
approaching reviews
* Atharva, you are overthinking this! I just use a straightforward {
editor + MUA + git } stack and go with the flow!
I'm a small-time contributor, but I do read the mailing list regularly.
As such, I'm not subscribed to the list; I read it on lore.kernel.org
or public-inbox.org (nicer colors!). The UI of public-inbox is very clear
with respect to threading, and the front page also lists messages in
a way that it is easy to quickly see what's new.
When I want to reply to a message that I read on the list, I import it
into a "Git mailing list" IMAP folder in my Gmail account so that I can answer
using my mail client (Thunderbird for now since Apple Mail has been reliably
crashing at launch for the last months) and quote relevant parts of the message.
To import a thread from the mailing list I use a combination of the excellent
'b4' tool, developed by the kernel community [1], and 'git imap-send'. It's
basically this:
$ git config --get alias.ml-imap
!f() { b4 mbox -o- $1 | git imap-send; }; f
This sometimes does not work if some messages in the thread were not created
using 'git format-patch', since 'git imap-send' expects the "From", "Date"
and "Subject" headers in a certain order. So I created a small Python script,
'git in', for this case [2].
For small and simple reviews, I also simply import the patches into Thunderbird
and reply inline. If I want to do a more in-depth review and browse the code as
modified by a series, I fetch the contributor's branch and take a look locally.
More often than not though people do not provide a 'git fetch'-ready link in their
cover letter. So in that case I use 'b4 am' [1] to fetch the latest version of a series
and apply it locally. Before 'b4' was created I used 'git pw' [3], a command line
client for Patchwork, and the Git patchwork instance at [4], but these days I prefer
'b4' as it's more closely integrated with public-inbox.
For my own contribution I use Gitgitgdaget [5], it handles almost everything needed
for git.git contributions: keeping track of the CC list for
me, updating the re-roll count, adding the In-Reply-To header such that subsequent
versions of the series are sent as a response to the cover letter of the previous version,
generating a range-diff against the previous version, providing a 'git fetch'-ready tag,
commenting on the PR when the series is mentioned in Junio's "What's cooking", etc.
Some things it does not support are: sending a patch as a response to some random
mail on the list, which is sometimes useful, reading the commit notes to generate
in-patch commentaries [6], customizing the diff generated by 'format-patch'.
Other things are listed at [7].
Recently I've also been using only the terminal with Gitgitgadget:
I use 'git branch --edit-description' to write my cover letter,
and then use the 'gh' GitHub CLI [8] to open my PR:
$ git config --get-regexp alias.desc*
alias.desc-title !git config branch.$(git branch --show-current).description | head -1
alias.desc-body !git config branch.$(git branch --show-current).description | tail -n+3
$ gh pr create --title "$(git desc-title)" --body "$(git desc-body)" --head phil-blain:$(git branch --show-current)
I hope this provides a different perspective!
Cheers,
Philippe.
[1] https://pypi.org/project/b4/
[2] https://gist.github.com/phil-blain/d350e91959efa6e7afce60e74bf7e4a8
[3] https://patchwork.readthedocs.io/projects/git-pw/en/latest/usage/
[4] https://patchwork.kernel.org/project/git/list/
[5] https://gitgitgadget.github.io/
[6] https://github.com/gitgitgadget/gitgitgadget/issues/173
[7] https://github.com/gitgitgadget/gitgitgadget/issues
[8] https://cli.github.com/
What tools, systems and workflows do you find valuable in your
day-to-day work? In particular I’d be happy getting insights
like:
* Any strategy or approach to work, kind of like the example I
quoted
above
* Any scripts and tools that assist you
* Opinionated handling of multiple in-flight series and methods
to
approaching reviews
* Atharva, you are overthinking this! I just use a
straightforward {
editor + MUA + git } stack and go with the flow!
I'm a small-time contributor, but I do read the mailing list
regularly.
As such, I'm not subscribed to the list; I read it on
lore.kernel.org
or public-inbox.org (nicer colors!). The UI of public-inbox is
very clear
with respect to threading, and the front page also lists
messages in
a way that it is easy to quickly see what's new.
When I want to reply to a message that I read on the list, I
import it
into a "Git mailing list" IMAP folder in my Gmail account so
that I can answer
using my mail client (Thunderbird for now since Apple Mail has
been reliably
crashing at launch for the last months) and quote relevant parts
of the message.
To import a thread from the mailing list I use a combination of
the excellent
'b4' tool, developed by the kernel community [1], and 'git
imap-send'. It's
basically this:
$ git config --get alias.ml-imap
!f() { b4 mbox -o- $1 | git imap-send; }; f
This sometimes does not work if some messages in the thread were
not created
using 'git format-patch', since 'git imap-send' expects the
"From", "Date"
and "Subject" headers in a certain order. So I created a small
Python script,
'git in', for this case [2].
For small and simple reviews, I also simply import the patches
into Thunderbird
and reply inline. If I want to do a more in-depth review and
browse the code as
modified by a series, I fetch the contributor's branch and take
a look locally.
More often than not though people do not provide a 'git
fetch'-ready link in their
cover letter. So in that case I use 'b4 am' [1] to fetch the
latest version of a series
and apply it locally. Before 'b4' was created I used 'git pw'
[3], a command line
client for Patchwork, and the Git patchwork instance at [4], but
these days I prefer
'b4' as it's more closely integrated with public-inbox.
For my own contribution I use Gitgitgdaget [5], it handles
almost everything needed
for git.git contributions: keeping track of the CC list for
me, updating the re-roll count, adding the In-Reply-To header
such that subsequent
versions of the series are sent as a response to the cover
letter of the previous version,
generating a range-diff against the previous version, providing
a 'git fetch'-ready tag,
commenting on the PR when the series is mentioned in Junio's
"What's cooking", etc.
Some things it does not support are: sending a patch as a
response to some random
mail on the list, which is sometimes useful, reading the commit
notes to generate
in-patch commentaries [6], customizing the diff generated by
'format-patch'.
Other things are listed at [7].
Recently I've also been using only the terminal with
Gitgitgadget:
I use 'git branch --edit-description' to write my cover letter,
and then use the 'gh' GitHub CLI [8] to open my PR:
$ git config --get-regexp alias.desc*
alias.desc-title !git config branch.$(git branch
--show-current).description | head -1
alias.desc-body !git config branch.$(git branch
--show-current).description | tail -n+3
$ gh pr create --title "$(git desc-title)" --body "$(git
desc-body)" --head phil-blain:$(git branch --show-current)
I hope this provides a different perspective!
Thanks for the detailed reply!
I like that it covers a lot about how you retrieve patches and
respond
to reviews.
You have convinced me to give Gitgitgadget a try for my next patch
:^)