I think in 2026 it's hard to make a video look this "bad" without it being a clear aesthetic choice, so not sure you could find this video in another setting.
I have trouble with code reviews because I can't run the code from the review GUI, so I usually look at the tests run in CI or pull and run it myself, if possible. Is this not a problem other people have? Is this a tooling problem?
By putting breakpoints in the code, and seeing what the changed lines do, I can compare the output line by line with my mental model of what should be happening, and this thoroughly helps me verify the changes.
I don't think I ever try to verify the correctness of the code in code review. That seems hopeless to me. The original developer should be assumed to produce working code, which is covered with tests and maybe will go through QA (if you have that). Of course there are occasional bugs you can spot, but the main goal is to review the architectural approach and code clarity. You can also note if something isn't properly covered with tests. If you managed to make any security, performance, or edge case handing suggestions, that's a nice bonus.
Maybe we're in a very different context, but to me if you can't understand what the code does without a debugger, then you ask the author to make the code clearer.
For coordinate transforms specifically, I also like to run through the whole chain of available, implemented transforms and back again - asserting I have the same coordinate at the end. One method might be wrong, but they "can't" all be wrong.
Yah, I wrote a `f(f^-1(x)) == x` test but ended up cutting for brevity. Also, running through every possible transform seems like a pain to debug if the error is somewhere in the middle. Perhaps it would be better to test every pair using the `GENERATE` clause in catch. That way you could narrow it down to two different algorithms.
Really interesting that nlohmann isn't fully compliant. What cases are these?
It seems to me though that if you're encountering the edges of json where nlohmann or simple parsing doesn't work properly, a binary format might be better. And if you're trying to serialize so much data that speed actually becomes an issue, then again, binary format might be what you really want.
The killer feature of nlohmann are the the NLOHMANN_DEFINE_TYPE_INTRUSIVE or NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE macros that handle all of the ??? -> json -> ??? steps for you. That alone make it my default go to unless the above reasons force me to go another direction.
I'm really trying to understand, and not to be too negative. I get coming up with a solution to a problem, and finding it neat locally. But before posting to HN, one might realize that these solutions that git provides existing tools for is better than maintaining this.
I'm also confused by all the comments just blindly commenting in the affirmative or providing suggestions. Are we all bots?
But before posting to HN, one might realize that these solutions that git provides existing tools for is better than maintaining this.
One might. But not everybody knows about those existing tools. Taking myself as an example: I've been using Git since nearly the time it was released and I had no idea that git had aliasing built in. Sometimes things just never come up and people don't find out about them. shrug
Hi! Author here. Some of these can indeed be an alias, others.. not so much. `git-root` for example is more-or-less a one-liner, meanwhile `git-mode-restore` is a ~840 loc python script.
I do use git aliases but trying to do anything non-trivial in them seems rather counter-productive so I'm confused about everyone suggesting it :P
Hey. I think my point is that writing and maintaining 900 lines of code is an option, and another option is to figure out how to not write and rely on 900 lines of code. I looked through git-more-restore a bit and I think you're trying to reverse permission changes in your working branch back to what's on HEAD.
I think a way to do this is to not let git track that in the first place, with some variation of:
It seems to me like a shallow reading and dismissal of your work. Which is sad. For what it's worth I'll be giving it a go as soon as I'm back at work on Tuesday.
EDIT: I saw your other comment (incorrectly) claiming that git remote prune origin will do the job. I don't know of any git trickery that can do the job. And believe me I'd love it if there was something.
That looks fine and will generally work, except when the current branch is one of the ones to be deleted.
The script in OP handles that edge case by switching to the main branch before deleting. That may or may not be intuitive but I think it's a reasonable response. The script also prints error messages for various other bad inputs. Once you strip all that out it's only a few lines long.
I'm going to assume you have about as many years of experience as me based on your profile, but if you're going to argue that maintaining this script - for the sole convenience of deleting a branch out from underneath you - is worth it, then there's nothing more I can do to help you.
You're being really dismissive. Handling bad inputs and edge cases, and including help texts, is the sort of requirement that necessitates moving away from one-liners towards a more structured repository.
I have an alias "git prune-branches" that deletes branches that remote has deleted. Is that what you are loking for? Cannot check the code right now but will try to get back tomorrow.
The trouble is that git aliases aren't composable and you can't install them. Each installation has its own aliases. If you are in a new machine you must define the aliases yourself. This also makes git aliases have poor discoverability.
Compare this with another tool that lets people extend its own command, cargo. You can do cargo install <something> and then run cargo <something>.
As a culture we need to move away from “just write these things yourself/copy these aliases and maintain them”. It makes things too much of a rite of passage.
No, I have never used NPM directly. Why do you ask?
Most tech folks in IT that I've known tend to just accept defaults, whether they're in vscode, a command line, or joining a new project. They don't seem to think in terms of "this is annoying/inefficient, how can I make it better?"
I should get "10x engineer with my git aliases" put onto a t-shirt :)
You’re suggesting not to use a functionality built into got from early days that naming a script git-something and putting it on your PATH gives you a sub command of “git something”.
Why do you disagree with this early decision from git?
This was my first thought as well. This might be an indictment of how obscure/confusing some git invocations are...hence the alias to human readable names.
It is kind of interesting that there is much interest, work and maintenance on these over-complications...There seems to be a related repo - git-extras - that does the same as this repo, and has 17k stars.
As someone of asian descent, I find it interesting how so many of these comments have such a stereotypical software engineer's "why don't they just XYZ" statement and its pretty eye opening.
I know I'm guilty of this at times too, but this example is really funny to me, and I guess I'll try rein in my assumptions that people are irrational in the future.
This pattern is pretty common on HN. Shallow dismissal and or overconfident alternative solution coming from those without any domain expertise (but that's okay because knowing how to code magically makes your ideas worth entertaining apparently).
