In git, commits play competing roles. They represent the mechanical history of your codebase, letting you restore/merge the state at various points. They're also often used as a legible, coherent history meant for reading or git bisect.
These two uses are at odds with each other – for the mechanical part, you want to make lots of small commits all the time, and for the legible part you want to have a small number of meaningful changes.
There are ways around this within git – for example, git rebase -i lets you create a new set of reorganized commits that have the same end result as your original commits. But all of these methods have enough friction that I've never seen a team actually stick to them.
I've been playing around with jj, a version control system on top of git. jj works seamlessly with existing git repositories/commands, and you can undo all operations, so trying it is very cheap.
jj gets around this problem by explicitly having separate concepts for Revisions (representing the mechanical history) and Changes (representing
... show moreIn git, commits play competing roles. They represent the mechanical history of your codebase, letting you restore/merge the state at various points. They're also often used as a legible, coherent history meant for reading or git bisect.
These two uses are at odds with each other – for the mechanical part, you want to make lots of small commits all the time, and for the legible part you want to have a small number of meaningful changes.
There are ways around this within git – for example, git rebase -i lets you create a new set of reorganized commits that have the same end result as your original commits. But all of these methods have enough friction that I've never seen a team actually stick to them.
I've been playing around with jj, a version control system on top of git. jj works seamlessly with existing git repositories/commands, and you can undo all operations, so trying it is very cheap.
jj gets around this problem by explicitly having separate concepts for Revisions (representing the mechanical history) and Changes (representing the logical history.)
Revisions are saved every time you do anything in jj, even with commands like jj log. Amongst other things, this lets you undo any command.
Changes, unlike commits, can be edited after creation. Suppose you have Change 1 -> Change 2 -> ... -> Change n, and then notice you made a typo in Change 1. In git, I would usually just make fixing the typo Commit n + 1, and not bother to go back, rebase, etc. In jj, I can just edit Change 1.
I've only been trying this for two weeks, but I like it a lot so far – I find myself making PRs with much cleaner commit histories, and experimenting more because I know I can just undo when needed.
Ben Weinstein-Raun
in reply to Satvik • • •Satvik
in reply to Ben Weinstein-Raun • •I've asked for more specific feedback, and the complaints often come down to "nothing I've done has been like this" and "most of development is web development." That might be true, but we don't have a website/web app, and we're pretty specific about the work involved in both the job description and the phone interview.
(We have had other feedback that's helpful)
Generally, everyone who's done well on this question and joined has been a strong hire, though we've also hired some people who didn't do well that specific question. So I'm pretty sure it's a good question. I'm just a little amused/dismayed at how many people seem to think "realistic" means "web development."
Ben Weinstein-Raun likes this.