Johannes Altmanninger
Johannes Altmanninger
I believe if you want to merge a bunch of commits, then having one "merge base" (the common ancestor) is enough, no need for more. `git merge-tree` can't do octopus...
oh wow, thanks for the clarification!
Sure A good strategy is to translate what Git does to Python. Both implementations have `sign_buffer()`, but ours does not respect `gpg.format`.
One problem is that Git does not expose a shared library with `sign_buffer()`. We don't want to shell out to `git commit` because that does more than we want to,...
On the topic of extensions, a nice feature is the ability [jump to the corresponding line in source code](https://github.com/mawww/kakoune/blob/master/rc/filetype/diff.kak#L24-L155) and to a lesser extent [apply the selected diff](https://github.com/mawww/kakoune/blob/06743119458e425b7525c6aa424a54077bc64244/rc/tools/patch.kak#L1-L12).
the hardest part is reverse engineering the github API. An obvious workaround is to post the literal (per commit) prr-files as comments on github, I wonder how well that is...
alternatively we could call `setsid` in the forked child, and perhaps double-fork additionally (for some added safety)
Same behavior here on 17.0.1, except that files are not actually deleted. Will probably be fixed by #540.
Reverting sounds fine. If we had never added the backgrounding behavior, I'd have doubts about adding it because users can always copy `tmux-terminal-impl`. But since it already worked, it seems...
Is there a use case where one wants to be notified once the popup is closed? I guess there are but probably not so important