I've worked with git using the mega-merge approach, and one thing I found is that git-absorb won't merge commits into anything that precedes a merge. It works fine for absorbing changes into earlier commits on a feature branch, but not from the WIP branch back into the multiple feature branches that are the parents of the mega-merge. jj handles this with no problems.
I’ve been using Ctrl-s for years. Nothing else uses it because it’s historically been used for terminal flow control, but that doesn’t really have much use in a graphical terminal with history and scrollbars and so I’ve never missed it. Has similar two-finger ergonomics to the Ctrl-a bind as well.
edit: oh, and I think Ctrl-space is the keystroke to get a nul character, and vi uses that character to insert the last entered piece of text in insert mode. It looks like Ctrl-@ does the same things, but tmux might not be able to tell the difference either.
Yeah, you need to rebase the tip of the feature branch stack. git will then update all the refs that point to ancestor commits that are moved. So in this case
I just flashed Tasmota on to three Sonoff S26’s without any soldering. I did need a USB to serial adapter to connect to the serial and power pins - I got one that included an ESP-01 so I knew it should work [0]. I also needed some bits of wire and crocodile clips, but that's all. The S20 is easier by all accounts, but I didn't know that until I'd already got the S26's. Having three to flash, I was motivated to figure out a solution that didn't involve soldering.
As a Windows outsider, I'm puzzled why programs used as part of the Chrome build system (which I'd expect to only use console I/O) are using APIs that cause interactions with the GUI? By analogy, is this not like gcc redundantly setting up a connection to the Xserver each time it is run?
(I'm making an assumption that NtGdiCloseProcess is part of the GUI API (GDI == Graphics Device Interface) which is why it may interact with the GUI message passing.)
Ah, ok. So the issue is mixing binary packages from different distributions or different releases of the same distribution (the Debian doc mentions mixing Debian stable and testing for example). If that's what Mint are doing then I'm surprised they aren't stuck in perpetual dependency hell.
Hmm; I'm puzzled by a contradiction between this and another recent article. From this article we learn that we shouldn't do this:
"Secondly, they are mixing their own binary packages with binary packages from Debian and Ubuntu without rebuilding the latter. This creates something that we in Debian call a "FrankenDebian" which results in system updates becoming unpredictable <https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_Frank.... With the result, that the Mint developers simply decided to blacklist certain packages from upgrades by default thus putting their users at risk because important security updates may not be installed."
"Nobody else requires that you rebuild every package before you can redistribute it in a modified distribution - such a restriction is a violation of freedom 2 of the Free Software Definition, and as a result the binary distributions of Ubuntu are not free software."
I appreciate that the latter one is discussing a hard requirement as a result of Canonical's IP licensing. But the former seems to indicate that it would be bad practice to just copy all of Ubuntu's (or Debian's) binary packages and build a new derivative distribution on top of it. Is the latter piece arguing in part for a freedom that would be a really bad idea in practice?
From this comment on the git-absorb issue tracker I wouldn't expect it to be fixed soon either: https://github.com/tummychow/git-absorb/issues/134#issuecomm...