Once I discovered how git apply can take diff files (or patch files) as input, I stopped using git stash in favor of plain old files. Easier to list and browse the contents of prior edits, also you can grep the files as method of search. I’ve even found myself copying and editing the diffs before applying.
I personally approaches stashes as undoable "clean up", and I never have anything really important that I want to save there. If I do have something like that, I just commit with a "WIP <some-descriptive-string>" message and don't push it, then a "git reset --mixed HEAD^" when I want to get back to it.
However, just FYI: you can "grep" your stashes really easily if you want to. just "git stash list -p" gives you the diffs for all the stashes, by default in "less" where you can search them, but you can pipe it to grep if you want. I somewhat frequently do that with "git log", if I want to know "when did this variable change?" or whatever, just "git log -p" to get the log with diffs in less, then search for whatever it was with a slash.
You’ll also want to familiarize with “git apply -3 <file name>”, for when a diff can’t be applied cleanly. It will try “harder” to merge (three way method) and if it still fails it invokes the conflict merge “UX”:
git diff an pipe works, but committing and then `git format-patch` can export multiple patches and then includes metadata (commit message, date, author, etc.) which can make reasoning about such files a lot easier. In a plain diff you only got filename as metadata.
I like doing it with aerc [1]. It's even possible to use aerc in parallel to another email client. Just open aerc for git-related emails, and that's it!
Exchange historically had a tendency to mangle emails sent through it (whitespace changes, line wrap, etc), which is obviously bad news for patchmails. I dunno if it's any better these days.
Yeah, I used DAVMail with Emacs+MSMTP+MPOP+notmuch for ages. Works really well, the only occasional thing I had to do was reauthenticate the token, which pops up in a browser window.
Once I discovered how git apply can take diff files (or patch files) as input, I stopped using git stash in favor of plain old files. Easier to list and browse the contents of prior edits, also you can grep the files as method of search. I’ve even found myself copying and editing the diffs before applying.
That is a very neat trick, I agree.
I personally approaches stashes as undoable "clean up", and I never have anything really important that I want to save there. If I do have something like that, I just commit with a "WIP <some-descriptive-string>" message and don't push it, then a "git reset --mixed HEAD^" when I want to get back to it.
However, just FYI: you can "grep" your stashes really easily if you want to. just "git stash list -p" gives you the diffs for all the stashes, by default in "less" where you can search them, but you can pipe it to grep if you want. I somewhat frequently do that with "git log", if I want to know "when did this variable change?" or whatever, just "git log -p" to get the log with diffs in less, then search for whatever it was with a slash.
Oh that’s clever, I’ll try that out. Looks like you could just do a git diff > file.patch.
Neat.
You’ll also want to familiarize with “git apply -3 <file name>”, for when a diff can’t be applied cleanly. It will try “harder” to merge (three way method) and if it still fails it invokes the conflict merge “UX”:
<<<<<<<<<
=========
>>>>>>>>>
There's also Neil Brown's "wiggle" program for applying patches that don't apply.
https://github.com/neilbrown/wiggle
although on debian based systems I think you can just "apt install wiggle"
git diff an pipe works, but committing and then `git format-patch` can export multiple patches and then includes metadata (commit message, date, author, etc.) which can make reasoning about such files a lot easier. In a plain diff you only got filename as metadata.
Thank you, will try. Useful bit of knowledge.
That’s a great idea, and very timely for me.
I like doing it with aerc [1]. It's even possible to use aerc in parallel to another email client. Just open aerc for git-related emails, and that's it!
[1]: https://drewdevault.com/2022/07/25/Code-review-with-aerc.htm...
Maybe slightly O/T, but has anyone found a decent way to `git send-email` with email hosts that demand OAuth? (looking at you Outlook and Gmail)
I use an app password but https://github.com/AdityaGarg8/git-credential-email apparently supports OAuth with Gmail, yahoo and outlook
I think you could set up postfix to smtp forward to those services. So it could handle the oauth2 and you wouldn’t need to configure your client
For Gmail, you can use https://github.com/google/gmail-oauth2-tools/tree/master/go/....
I use msmtp with a tool from the oauth2-tools repo to do the rotation token dance. Need to register your own app with Google though.
Generating app passwords for those would work.
Yeah, I use an app specific password with Gmail, like the setup suggested by https://git-send-email.io/#step-2
Exchange historically had a tendency to mangle emails sent through it (whitespace changes, line wrap, etc), which is obviously bad news for patchmails. I dunno if it's any better these days.
davmail supports smtp through outlook(365)
Yeah, I used DAVMail with Emacs+MSMTP+MPOP+notmuch for ages. Works really well, the only occasional thing I had to do was reauthenticate the token, which pops up in a browser window.
If you work with git and patches a lot, stgit is worth a look.
https://stacked-git.github.io
View the e-mail raw in your browser, select all, copy, paste into git apply.
Then you don't need that message to be in a file-based inbox that is accessible from your git repo.
And in that case you are still likely going to have to copy and paste something to get the correct path.
It looks like Apple Mail has plugin support, I wonder if you could author a plugin that’d provide a button to apply the diff.
[dead]