I like the idea of 'G' to filter hunks. The perl script does not exist since git v2.40.0 so I don't think the installation instructions work for recent versions of git as there is no way to stop 'git add -p' from running the builtin version. I see this is MIT licenced but the code is very closely based on the perl script which is licensed under the GPLv2.

huh. I guess this is a prototype for features that will have be submitted to the upstream version. There was a feature in development for something like `git add -G <regex>`, maybe a decade ago, that never got completed.

As for licensing, I'm happy to change the license. I have no strong feelings on the subject, and don't know what restrictions GPLv2 imposes on a port to another language.

It would be really nice to have this upstream - I don't know if the upstream implementation being in C now makes that easier or harder. As for the license I think because this is so closely based on GPL code it would be safer to use the same license.

I use an app password but https://github.com/AdityaGarg8/git-credential-email apparently supports OAuth with Gmail, yahoo and outlook

I tried this with Gmail and Outlook. Works flawlessly and also doesn't need to authenticate frequently. The Authen::SASL thing was a catch though.

git-send-email also has some quirks for Outlook which have been recently merged.

> eval "$CMD"

That means you will eval all the filenames, so if you have a file with spaces in it will appear as two files, if there is a `$` in the name it will trigger parameter substitution and so on for the other shell meta-characters.

Yes, that could be true. I'm not great in Bash. Be careful. These types of error are why I don't use Bash. I just wanted to give an example in a commonly used scripting language. The main point here is to check ARG_MAX.

> It’s frustrating that tarball urls are a proprietary thing and not something that was ever standardized in the git protocol.

`git archive --remote` will create a tarball from a remote repository so long as the server has enabled the appropriate config

For rebasing `--reapply-cherry-picks` will avoid the annoying fetching you saw. `git backfill` is great for fetching the history of a file before running `git blame` on that file. I'm not sure how much it will help with detecting upstream cherry-picks.

Oh, interesting! Tbh I don't fully understand what "--reapply-cherry-picks" really does, because the docs are very concise and hand-wavy, and _why_ it doesn't need the fetches? Why it is not the default?