💾 Archived View for gemini.susa.net › sr.ht_patches_notes.gmi captured on 2023-07-10 at 13:56:25. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-11-30)
-=-=-=-=-=-=-
So, I recently learned that email is a good way to communicate Git patches. Drew DeVault has put together a really comprehensive guide on using this, including a round-trip test repository so you can practise.
I was initially reticent to bother - my patches were minor, one-line affairs. However, I have been concerned for quite a while about GitHub et al. starting to 'own' the issues and patch process, and email makes a lot of sense as an alternative.
It takes a little time and effort to understand how to send patches this way, though by this I mean like 30 leisurely minutes or so!
Drew's setup instructions and tutorial.
For reference, the commonly used commands are shown below. Really, just 'git send-email', though there's a config to auto-set the subject prefix on a per-project basis. This is specific to Drew's handling of emails, but it makes good sense to follow the practise if sending patches to other email accounts.
# In the project directory (e.g. gmnisrv), once after cloning the repo do: git config format.subjectPrefix "PATCH gmnisrv" # After committing, to send the associated changes do: git send-email --to="~sircmpwn/public-inbox@lists.sr.ht" HEAD^ # If modifications are required to the commit, these commands apply: git commit --amend git send-email -v2 --to="~sircmpwn/public-inbox@lists.sr.ht" HEAD^
Note, the -v2 flag, in one of the send commands above, I think refers to --reroll-count=<n> in git-format-patch, which is invoked by git-send-email. It just marks the patch description as second (or third, etc.) revision.
That's it! Simple, when you get right down to it. Thanks to Drew for producing comprehensive docs and, more generally, for making use of this mechanism which has been available in git for years - it should really be used more widely. When we allow web sites to 'spoon feed' us, we never learn to use spoons!
The other thing that came to mind is how dangerously relegated email has become. Only a handful of the machines I use are configured to send email, and big email providers like Google are really configured to reject most email. It's a precarious situation, and needs some thought. The first thing I'm going to do is make sure I have a secured smart-host available for all my servers to use.
For the full man-page, use 'git help send-email'
Git was using nano or whatever for its editor. To change this to Vim:
# You can never have too many notes of how to have Vim invoked... git config --global core.editor vim
If you have other changes on master, but you need to force head to be the remote:
# First branch the current state of the repository. git commit -a -m "Saving all work to create a new branch" git branch my-safe-branch # Then fetch remote commits, and reset HEAD git fetch origin git reset --hard origin/master