Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Email and Git = <3

git-send-email.io

Post reply on HN
Print view View original

51–60 of 265 posts

Re: Email and Git = <3

#51

Post by pjerem »

ploum wrote: post #31
BaculumMeumEst wrote: post #21

I 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.

I have no great love for GitHub, I avoid it for my own projects but their official cli client is pretty functional and there are just tons of other clients, graphical or not for GitHub, GitLab etc …

I say that as someone who don’t like GitHub, but overall it’s far from the worst tool an employer may impose to its employees.

Re: Email and Git = <3

#52

Post by pjm331 »

dewey wrote: post #27
keepamovin wrote: post #23

Earlier quoted context omitted.

:) Thank you! I guess I prefer text. And deeply there's a difference between staying in text, and moving to GUI. The medium is the message^0, and even if the process is "the same", everything becomes different because you're no longer within the text world. 0: https://en.wikipedia.org/wiki/The_medium_is_the_message

I know it's not the same, but that's also why I prefer GitLab's "--push-option=merge_request.create" which creates a PR from the CLI without needing me to open the website and clicking a button. I'm still annoyed daily that this doesn't exist for GitHub.

GitHub has a CLI https://cli.github.com/manual/gh_pr_create

Re: Email and Git = <3

#53

Post by tlamponi »

oefrha wrote: post #48
severus_snape wrote: post #44

Earlier 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

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.

Every mail server/provider that provides 2FA that I used allows for configuring "tokens" (called a bit different everywhere) which are a high entropy random string, and some of them require TFA only for IMAP or POP, i.e., getting mail, not SMTP, i.e., sending mail.

Re: Email and Git = <3

#54

Post by oefrha »

emptysongglass wrote: post #39
BaculumMeumEst wrote: post #21

I 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…

It really kills the fun when contributing to any FOSS project that fetishizes these tools and holds them up as some kind of proof of hacker cred. I've given up. The latency is too high and the tools are terrible.

“Want to contribute? Subscribe to our mailing list that sends a hundred emails a day.” Nope.

Re: Email and Git = <3

#55

Post by ploum »

sneak wrote: post #42
ploum wrote: post #31

Earlier quoted context omitted.

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 c…

[flagged]

Re: Email and Git = <3

#56

Post by rascul »

oefrha wrote: post #48
severus_snape wrote: post #44

Earlier 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

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.

There are instructions provided for Gmail and some others:

https://git-send-email.io/#step-2

A tool from Google is mentioned and linked to:

https://github.com/google/gmail-oauth2-tools/tree/master/go/...

Re: Email and Git = <3

#57

Post by dewey »

pjm331 wrote: post #52
dewey wrote: post #27

Earlier quoted context omitted.

I know it's not the same, but that's also why I prefer GitLab's "--push-option=merge_request.create" which creates a PR from the CLI without needing me to open the website and clicking a button. I'm still annoyed daily that this doesn't exist for GitHub.

GitHub has a CLI https://cli.github.com/manual/gh_pr_create

Yes, but the advantage with the "push options" is that I can put it in my .gitconfig and it just works automatically when I do a git push without using some proprietary platform's cli.

Re: Email and Git = <3

#58

Post by sneak »

ploum wrote: post #55
sneak wrote: post #42

Earlier quoted context omitted.

“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 c…

[flagged]

That’s your bias showing; GitHub is primarily designed for getting work done, as it is a paid service that needs to serve its customers.

Re: Email and Git = <3

#59

Post by dnsmichi »

dewey wrote: post #27
keepamovin wrote: post #23

Earlier quoted context omitted.

:) Thank you! I guess I prefer text. And deeply there's a difference between staying in text, and moving to GUI. The medium is the message^0, and even if the process is "the same", everything becomes different because you're no longer within the text world. 0: https://en.wikipedia.org/wiki/The_medium_is_the_message

I know it's not the same, but that's also why I prefer GitLab's "--push-option=merge_request.create" which creates a PR from the CLI without needing me to open the website and clicking a button. I'm still annoyed daily that this doesn't exist for GitHub.

Thanks for sharing. GitLab team member here.

More GitLab push options are documented in https://docs.gitlab.com/ee/user/project/push_options.html

You can also add a parameter to merge the merge request when the pipeline succeeds. This can be handy for quick fixes that do not require reviews, and avoids unnecessary context switches.

# mwps BRANCHNAME

alias mwps='git push -u origin -o merge_request.create -o merge_request.target=main -o merge_request.merge_when_pipeline_succeeds'

Example from https://gitlab.com/sytses/dotfiles/-/blob/master/git/aliases... and https://about.gitlab.com/blog/2021/10/19/top-10-gitlab-hacks...

If you prefer deeper CLI integration, suggest installing the GitLab CLI: https://docs.gitlab.com/ee/editor_extensions/gitlab_cli/

Re: Email and Git = <3

#60

Post by tlamponi »

MatthiasPortzel wrote: post #28

> 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 core reason for this is that lots (all?) of "modern" mail user agents (MUA) mess with whitespace in their default configuration, which breaks patches as the indentation is all of and git is confused.

git send-email is made for this, and handles all edge cases correctly, but depending on your MUA and/or it's config, it can work pasting patch diffs in there just fine – the point is that, especially for newcomers, and for a few edge cases, it may hard to do correctly and so using the tool made for the job avoids friction for all sites.

ps. ZIP wouldn't be required, just use base64 encoding, that's basically what git send-email does, depending on the encoding, line length, ... of a commit.

Post reply on HN