Why not use a branch? This was the only surprisingly part to me. Won't this get messy when I try to pull the code later on? I don't know how the maintainer is going to merge my patch.
Email and Git = <3
41–50 of 265 posts
Re: Email and Git = <3
#42I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd. Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needless…
Organizations that insists on using a web interface and ever-changing click workflows not only drive away a significant number of very knowledgeable contributors, but they also form a weirdly irrational culture that fetishizes needlessly graphical content, marketing and fake-usability detrimental to learnability and integration with each user workflow.
“needlessly graphical” requires a citation when it’s clear that if you use a web GUI for this you address a market of potential contributors that is three to six orders of magnitude larger.
srht is really designed for (and thus only really useful for) lone wolf developers who collaborate rarely, if ever, and with a very small number of collaborators who collaborate infrequently. It is not built for large teams with constant active collaboration, it falls down for this use case.
It’s hobby software for hobby users. (I don’t think this is a bad thing, but you should be aware of the product design goals of its author.)
Re: Email and Git = <3
#43Why not use a branch? This was the only surprisingly part to me. Won't this get messy when I try to pull the code later on? I don't know how the maintainer is going to merge my patch.
You could do it in a branch if you want to, doesn't matter, as long as the diff/patch is based on the branch where upstream does its main work.
Re: Email and Git = <3
#44I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd. Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needless…
# do your code change
git commit
git send-email --to= -1
# amend your change
git commit --amend
git send-email -v2 --to= -1
Edit with minimal configuration:
cat ~/.gitconfig
[user]
email = your@mail.address
name = Your Name
[sendemail]
smtpuser = your@mail.address
smtpserver = smtp.whatever.com
smtpserverport = 587
smtpencryption = tlsRe: Email and Git = <3
#45I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd. Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needless…
# do your code change git commit git send-email --to= -1 # amend your change git commit --amend git send-email -v2 --to= -1 I'm not sure what is needlessly annoying and absurd. Edit with minimal configuration: cat ~/.gitconfig [user] email = your@mail.address name = Your Name [sendemail] smtpuser = your@mail.address smtpserver = smtp.whatever.com smtpserverport = 587 smtpencryption = tls
They said they found it difficult to configure, not that they found it difficult to use afterwards.
Re: Email and Git = <3
#46I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd. Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needless…
Configuring git send-email is trivial, definitively faster than creating an account at some web UI from a "source forge" – it's literally setting a handful of properties in the `.gitconfig` – and those are not specific to a project, but just your mail server settings you can reuse them for any project that accept patches over mailing lists.
And using it for a project that accepts this workflow is such a joy, no need to figure out weird merge request that make me re-enter all the information I had in my git commits already.
If it's only a few patches, say three, I can do a simple `git send-email --to mailing@list.example.com -3`, maybe throw in `--cover-letter` for some meta info if the changes are even big enough to require that, and be done.
Certainly to each their own workflow, and once can get accustomed to a lot of needless tasks and workflows, but how one can look at the bloated interfaces that try hard to add vendor-lock-in and say "this is so much simpler and easier to grasp" can IMO only mean they never tried this way in good faith. In the end sending a mail is trivial, and code changes are text (most of the time), it can hardly be beat in simplicity.
Anecdotally, most of our new hires from the last years had no experience with the email workflow, and a few weeks in most of them find it way better, while the rest finds it at least as good as the alternatives (and here they mean gitea or sourcehut, not the monsters that GitHub/Lab are).
Re: Email and Git = <3
#47Earlier quoted context omitted.
# do your code change git commit git send-email --to= -1 # amend your change git commit --amend git send-email -v2 --to= -1 I'm not sure what is needlessly annoying and absurd. Edit with minimal configuration: cat ~/.gitconfig [user] email = your@mail.address name = Your Name [sendemail] smtpuser = your@mail.address smtpserver = smtp.whatever.com smtpserverport = 587 smtpencryption = tls
They said they found it difficult to configure , not that they found it difficult to use afterwards.
[deleted]
Re: Email and Git = <3
#48I appreciate the effort here, but after learning the workflow and having to get all this set up on a few computers, having to configure git send-mail is honestly just needlessly annoying and absurd. Organizations that insist on using workflows like git send-mail and mailing lists not only drive away a significant number of potential contributors, but they also form a weirdly religious culture that fetishizes needless…
# do your code change git commit git send-email --to= -1 # amend your change git commit --amend git send-email -v2 --to= -1 I'm not sure what is needlessly annoying and absurd. Edit with minimal configuration: cat ~/.gitconfig [user] email = your@mail.address name = Your Name [sendemail] smtpuser = your@mail.address smtpserver = smtp.whatever.com smtpserverport = 587 smtpencryption = tls
You left out the entire configure SMTP step. Honestly I’m not even sure how to do that if your SMTP server requires 2FA and does not allow legacy app specific passwords.
Re: Email and Git = <3
#49Earlier quoted context omitted.
# do your code change git commit git send-email --to= -1 # amend your change git commit --amend git send-email -v2 --to= -1 I'm not sure what is needlessly annoying and absurd. Edit with minimal configuration: cat ~/.gitconfig [user] email = your@mail.address name = Your Name [sendemail] smtpuser = your@mail.address smtpserver = smtp.whatever.com smtpserverport = 587 smtpencryption = tls
They said they found it difficult to configure , not that they found it difficult to use afterwards.
If your system cannot relay mail correctly already, as most office setups are easy to configure to be able to provide that without extra config, at least for Linux setups, then the set up means having something like the following in their gitconfig:
cat .gitconfig
# snip
[sendemail]
to = default@list.example.com
annotate = yes
suppresscc = self
smtpencryption=tls
smtpserver=imap.example.com
smtpserverport=587
smtpuser=foo.bar@example.com
And that has to be done once, iow., in essence it's as hard a setting up an email fat client like thunderbird.
Re: Email and Git = <3
#50> Warning! Some people think that they can get away with sending patches through some means other than git send-email, but you can't. Could someone elaborate on this? Obviously it’s not intended, but is there anything wrong, from a technical standpoint, with using `git format-patch`, zipping the result, attaching it to an email using a GUI email client, and sending it to a maintainer who unzips and runs `git am`?
The point is being able to discuss and archive things via email. Using a zip file makes this moot.