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
A related tool that I've found useful over the years is Unison [1]. Think of it as rsync where you can interactively adjust the reconciliation algorithm between the two sides of the sync connection. It stores a hash of the file contents from the previous run for each file, so it can work out whether each side has changed since the last run. It then presents you with a GUI (or TUI) to review and adjust the reconciliation.
For the periods of my career where I've lived the two computer life (desktop and laptop), I've used Unison to keep substantial parts of my home directory in sync between the two machines.
I think pax was more of a POSIX replacement for cpio and tar. While those three and ar all could be used to bundle files together into a single file, only ar had the special affinity with the linker as a way of bundling object files together into libraries. The others were more aimed at backing up directories to a tape drive, as the example on the pax man page shows.
Unlikely. This kind of wireless thermostat has two parts: the thermostat itself, and a separate receiver box that's directly connected to the boiler. There's usually a pairing process that you can go through where the two parts negotiate a shared value used in the protocol; this prevents one thermostat unintentionally controlling other boilers. You can see this described in the Installation Guide for the thermostat linked from the article (it's called 'binding' in the guide).
My reading is that the first two CVEs are with rsync daemon, but the others are more general - I think "rsync server" is meaning the remote rsync process that is started when you use ssh to connect to the remote. Some of them suggest the rsync client (running on your machine) can be coerced to write to unexpected locations by a malicious rsync server specifically crafted to exploit these CVEs. One suggests a malicious rsync server might be able to reconstruct the contents of arbitrary files on the client using requests sent via the rsync protocol.
I guess the main takeaway is to be careful using rsync connections to machines that you don't trust.
It’s really handy to have a composable API for building SQL queries where different elements are contributed by different parts of the code. From example, having your authorisation code apply restrictions to queries through where clauses, joins, etc. to ensure a user only sees the records they are allowed to see.
I currently spend a large proportion of my time working in a Java code base that uses JDBC directly. There are many places where the complexity of the work to be done means code is being used to assemble the final SQL query based on conditionals and then the same conditional structure must be used to bind parameter values. Yes, in some places there are entire SQL statements as String literals, but that only really works for simple scenarios. There are also many bits of code that wrap up common query patterns, reimplementing some of what an ORM might bring.
I recently implemented soft deletion for one of the main entities in the system, and having to review every query for the table involved to see whether it needed the deleted_at field adding to the where clause took a significant amount of time. I think better architecture supported by a more structured query builder would have made this much easier. For me that’s the main benefit of an ORM.
I’ve been looking at codemod tools recently, just as a way to extend my editing toolbox. I came across https://ast-grep.github.io/, which looks like it might address part of this problem. My initial test case was to locate all calls to a method where a specific argument was ‘true’, and it handled that well - that’s the kind of thing an IDE seems to struggle with. I’m not yet sure whether it could handle renaming a variable though.
I guess what I’m looking for is something that
* can carry out the kind of refactorings usually reserved for an IDE
* has a concise language for representing the refactorings so new ones can be built quite easily
* can apply the same refactoring in multiple places, with some kind of search language (addressing the task of renaming a test parameter in multiple methods)
* ideally does this across multiple programming languages
Simpler explanation: Mac OS’s first release preceded Windows so they had to pick a side for themselves when first designing the system. See https://www.versionmuseum.com/history-of/classic-mac-os - the square on the left side of the front-most window’s title bar is the close button.
Sure it does - long press on the green maximise button and you get a little drop down. For me it includes "Enter full screen", "Tile Window to Left of Screen" and "Tile Window to Left of Screen". Tiling is like full screen but with two apps side-by-side rather than one.
If you want to maximise a window instead of going full screen (that is, make it as big as possible but not overlap the menu bar or dock), Option+Click on the green button or double click the title bar. macOS calls this "Zoom". Safari is atypical in that maximising it only changes the window's vertical height, but pretty much everything else maximises height and width.
All these options are on the 'Window' menu as well.
I’m designing a piece of user interface at the moment, and one thing I’ve been puzzled by is whether keyboard shortcuts should affect the focussed element. I’d love to find out if there are best practices in this area, and particularly if there are accessibility concerns I may not spot.
As an example, consider a page that primarily contains a list of items. I set each item up to be a focus target so tabbing through the targets will select each list element in turn.
If I add keyboard shortcuts to navigate the list (e.g. up/down cursor to select previous/next element), should my JavaScript drive focus to the selected element, or should I use an independent mechanism (adding a class, say) to mark the active element? Driving focus feels like the more ‘native’ approach, but I don’t know if there are downsides to potentially taking focus away from other elements on the page (for example).
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...