Is your feature request related to a problem? Please describe.
git-send-email is a historical feature yes, but still much used in some projects. My main forge is SourceHut, and so my main projects are hosted there.
People contribute to this kind of project by sending the commit with emails git send-email <revset>, and maintainer apply them with git am -3. Some email clients are very convenient for this, as Aerc.
The Git API for send-emails sucks, and no one ever manage to fix it. And so is the workflow for contributors. Keeping in mind which revisions of the commits they already sent is unconvenient. And I can also mention that the default git config are largely considered wrong (email prefix, annotate, etc).
edit: for those that never used git-send-email, here's a good getting-started:
I think Jujutsu can support send-email in a much better way. First because this workflow does not even need branches bookmarks. Also because it could fit perfectly with the discussed feature about Topics. If a Topic reference a bunch a commit, It is very easy to send a whole batch of email from them.
Describe the solution you'd like
We could implement something like jj email send [REVISIONS].... I am not sure yet if jj offer a am similar command. We could also do jj email apply [-r <REVISION>].
Sending emails could ask what is the mailto email address, and store it with dedicated configurations. The prefix project should also be configurable, but the default should be the project basename. The built emails should be fully compatible with mailbox, and can be applied by a git user. Because Jujutsu is able to track commit revisions, it can mark commits that needs to be re-sent, and use a correct revision id (-v2 -v3 -v4).
We have discussed mail support multiple times in the Discord and I'd really like to have the mail support in jj patch (#2702) with descriptive arguments.
Is your feature request related to a problem? Please describe.
git-send-email is a historical feature yes, but still much used in some projects. My main forge is SourceHut, and so my main projects are hosted there.
People contribute to this kind of project by sending the commit with emails
git send-email <revset>
, and maintainer apply them withgit am -3
. Some email clients are very convenient for this, as Aerc.The Git API for send-emails sucks, and no one ever manage to fix it. And so is the workflow for contributors. Keeping in mind which revisions of the commits they already sent is unconvenient. And I can also mention that the default git config are largely considered wrong (email prefix, annotate, etc).
edit: for those that never used git-send-email, here's a good getting-started:
=> https://git-send-email.io/
I think Jujutsu can support send-email in a much better way. First because this workflow does not even need
branchesbookmarks. Also because it could fit perfectly with the discussed feature about Topics. If a Topic reference a bunch a commit, It is very easy to send a whole batch of email from them.Describe the solution you'd like
We could implement something like
jj email send [REVISIONS]...
. I am not sure yet if jj offer aam
similar command. We could also dojj email apply [-r <REVISION>]
.Sending emails could ask what is the mailto email address, and store it with dedicated configurations. The prefix project should also be configurable, but the default should be the project basename. The built emails should be fully compatible with mailbox, and can be applied by a git user. Because Jujutsu is able to track commit revisions, it can mark commits that needs to be re-sent, and use a correct revision id (
-v2 -v3 -v4
).Describe alternatives you've considered
Additional context