Hi, I find the email based workflow quite powerful, however to be
honest I always find the first contribution to a project to be a bit
painful.
I think most of this pain would be alleviated if there was some message
printed to the console on `git clone https://git.sr.ht/...`, like:
Cloning into 'tmp'...
remote: Enumerating objects: 9, done.
remote: Counting objects: 100% (9/9), done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 9 (delta 0), reused 0 (delta 0), pack-reused 0
remote: This repository accepts email patches.
remote: Learn more at https://git-send-email.io/
remote:
remote: git config sendemail.to "list@example.com"
remote: git config format.to "list@example.com"
remote: git config format.subjectprefix "PATCH project"
---
Rationale for showing the `git config ...` config on https clone:
- I can copy/paste them immediately and make sure that my emails will
go to the right list (and with the right subject if prepared with
format-patch)
- Since this is displayed by the server, it is lost when doing a fork
(which is a good thing, since the fork may use another list)
---
As far as I know, this would mean two changes on git.sr.ht:
- add settings for the email patch (to and subjectprefix)
- display those settings on git clone via https
As a bonus, those settings could be displayed on the web as well, near
the hint "You can also use your local clone with git send-email.".
What do you think of such a feature?
If you think that it would be a welcomed addition, I can try to have a
look to propose some patches.
Thank you
Olivier
~oliverpool
On Mon Dec 5, 2022 at 3:38 PM CET, Olivier C wrote:
> - I can copy/paste them immediately and make sure that my emails will> go to the right list (and with the right subject if prepared with> format-patch)
This sure sounds convenient.
> As a bonus, those settings could be displayed on the web as well, near> the hint "You can also use your local clone with git send-email.".
This could also be helpful if the maintainer forgets to put the email in
the README or a CONTRIBUTING file.
--
Moritz Poldrack
https://moritz.sh
I like this idea. A potential problem is how the correct list for
patches can be determined, since a git repository can be in a project
with several lists. Maybe a heuristic of assuming that a list that ends
in -dev or -devel is the patch list?
On Mon Dec 5, 2022 at 9:38 AM EST, Olivier C wrote:
> Hi, I find the email based workflow quite powerful, however to be> honest I always find the first contribution to a project to be a bit> painful.>> I think most of this pain would be alleviated if there was some message> printed to the console on `git clone https://git.sr.ht/...`, like:> Cloning into 'tmp'...> remote: Enumerating objects: 9, done.> remote: Counting objects: 100% (9/9), done.> remote: Compressing objects: 100% (3/3), done.> remote: Total 9 (delta 0), reused 0 (delta 0), pack-reused 0> remote: This repository accepts email patches.> remote: Learn more at https://git-send-email.io/> remote:> remote: git config sendemail.to "list@example.com"> remote: git config format.to "list@example.com"> remote: git config format.subjectprefix "PATCH project">> --->> Rationale for showing the `git config ...` config on https clone:> - I can copy/paste them immediately and make sure that my emails will> go to the right list (and with the right subject if prepared with> format-patch)> - Since this is displayed by the server, it is lost when doing a fork> (which is a good thing, since the fork may use another list)>> --->> As far as I know, this would mean two changes on git.sr.ht:> - add settings for the email patch (to and subjectprefix)> - display those settings on git clone via https>> As a bonus, those settings could be displayed on the web as well, near> the hint "You can also use your local clone with git send-email.".>> What do you think of such a feature?> If you think that it would be a welcomed addition, I can try to have a> look to propose some patches.>> Thank you>> Olivier> ~oliverpool
On Mon Dec 5, 2022 at 12:11 PM EST, Sebastian LaVine wrote:
> I like this idea. A potential problem is how the correct list for> patches can be determined, since a git repository can be in a project> with several lists. Maybe a heuristic of assuming that a list that ends> in -dev or -devel is the patch list?
I think the idea is that the user can configure the mailing list in the
settings for their repository.
On Mon, 05 Dec 2022 15:38:15 +0100
Olivier C. wrote:
> I think most of this pain would be alleviated if there was some message> printed to the console on `git clone https://git.sr.ht/...`, like:> Cloning into 'tmp'...> remote: Enumerating objects: 9, done.> remote: Counting objects: 100% (9/9), done.> remote: Compressing objects: 100% (3/3), done.> remote: Total 9 (delta 0), reused 0 (delta 0), pack-reused 0> remote: This repository accepts email patches.> remote: Learn more at https://git-send-email.io/> remote:> remote: git config sendemail.to "list@example.com"> remote: git config format.to "list@example.com"> remote: git config format.subjectprefix "PATCH project"
IMO it's better to track any shared config iside the repo for this
purpose.
That's no less convenient than your proposal (either pick and copy
desired settings or include the config file(s) wholesale) and has some
advantages, too: it will work everywhere without any need for
server-side changes, and future updates will be propagated during next
pull (your proposal looks like a one-time thing during clone).
There are various ready-made solutions/tools/samples on the Internet,
e.g.:
https://stackoverflow.com/questions/18329621/how-to-store-a-git-config-as-part-of-the-repository
--
Štěpán
> IMO it's better to track any shared config iside the repo for this> purpose.>> That's no less convenient than your proposal (either pick and copy> desired settings or include the config file(s) wholesale) and has some> advantages, too: it will work everywhere without any need for> server-side changes, and future updates will be propagated during next> pull (your proposal looks like a one-time thing during clone).
Agreed; here’s a real world example. In my work I’m often under
tight deadlines, so I’m often passing around tarballs of repositories
(mercurial and git), then sending patches through email or chat. Files
in the repository have long outlasted the different servers and
outdated wikis. Getting write access to the servers can take weeks!
It’s a bonus when there are boring old files in the repository itself.
> IMO it's better to track any shared config iside the repo for this> purpose.
As far as I remember, this has been proposed and declined on the git
repository.
I can't find the source, the only thing that I found was a comment from
ddevault in 2019:
> This is actually something I plan on adding to git sooner or later.https://news.ycombinator.com/item?id=19577475
Maybe someone can find this discussion ? Or Drew can share its opinion.
---
Thinking more about this, I think storing the sendemail mailing list as
well as the prefix information in a structured way could be used on
multiple places:
- on the git.sr.ht page (along the clone info)
- on the hub.sr.ht lists page (the "dev" could list the associated
sources and expected prefixes)
(having them on the lists.sr.ht page is likely more problematic, since
it would inverse the relationship)