71–76 of 76 posts
Maybe I missed it, but I think it would be great to also explain what happens on the other end of this process. What does someone do when they receive a patch?
git apply filename.patch
Earlier quoted context omitted.
> mailing lists are clunky, intuitive, and simply horrible for large discussions On the contrary, I largely prefer mailing lists for non-code discussions (i.e. things that are not code review or filing bugs). When Swift's mailing lists moved to Discourse I realized that I stopped interacting with it as much because it was more inconvenient to work with (especially on mobile).
If you self-host your own git service, you could email everyone e.g. in a specific organization very easily. On something like GitHub it's nearly impossible, but when you own your data its just a database query + email away.
Earlier quoted context omitted.
Ooooooo. Is there such a thing as SSMTP/SIMAP (i.e. something that is to SMTP/IMAP as SFTP is to FTP - i.e. an SSH-based thing that sends and/or receives mail to/from a mail server)? It'd be badass to be able to literally just use my SSH keys to authenticate when sending/receiving mail.
You can literally invoke imapd over ssh and it will preauthenticate as the user that invoked imapd. I used to do this with PINE 20 years ago. Good luck getting any of the big MSPs to support it, though.
Earlier quoted context omitted.
The Google implementation of application specific passwords is horrible . There's nothing application specific about it -- it's valid for at least mail, calendar, and contacts, with no way to limit the scope. It ends up being a password that effectively bypasses all MFA on your Google account. Where do you store such a password? That's a powerful credential to be regularly unlocking. I should be able to create a cred…
If you want that level of granularity then you pretty much have to write an app but it's absolutely possible. https://developers.google.com/gmail/api/auth/scopes
I've been toying with writing a credential helper to obtain the oauth bearer token, but Authen::SASL::XOAUTH2 still needs to be written so that git-send-mail knows how to use it.
Can only speak for myself, but I didn't understand enough context to get much out of the site. I'm used git for small, personal collaborations, so I don't know why it sends email or when you would want it to do that. I don't know what a "patch" means here and why you use email with them. If I'm not your target audience, then that's fine, but it might be helpful to have some background on this. Otherwise, the site and…
The idea is that in order for multiple people to collaborate, most of the time you will need a service like Github, Bitbucket or perhaps something you can run yourself. This is a different workflow. Instead of staying in sync via a hosted service, people stay in sync and send 'pull requests' via email.
``git daemon`` is entirely self-contained and permits the git:// protocol for clones/push/pull etc
``git instaweb`` will piggyback a simple git web service on top of a number of httpd's including lighttpd.
I'm sure that git's homepage used to use instaweb for it's repo access, but it seems they've switched to github :(
Earlier quoted context omitted.
Ooooooo. Is there such a thing as SSMTP/SIMAP (i.e. something that is to SMTP/IMAP as SFTP is to FTP - i.e. an SSH-based thing that sends and/or receives mail to/from a mail server)? It'd be badass to be able to literally just use my SSH keys to authenticate when sending/receiving mail.
You can literally invoke imapd over ssh and it will preauthenticate as the user that invoked imapd. I used to do this with PINE 20 years ago. Good luck getting any of the big MSPs to support it, though.