More on Version Control(bramcohen.com)
bramcohen.com
More on Version Control
https://bramcohen.com/p/more-on-version-control
43 comments
You're talking about a new VCS but I don't know how even git with sha-256 will gain any traction because I don't see how you can support both...
Tooling can support both (e.g. don't assume all hashes have the length of a SHA1, etc.); but they can't be used together in one repo.
The great thing about jj is that it is backend agnostic; it is the best gateway to newer version control systems.
Does jj write to the .git directory or use git’s libraries (I assume they exist)?
JJ doesn't directly touch the `.git` directory, it uses gitoxide¹ to perform git operations.
¹https://github.com/GitoxideLabs/gitoxide
¹https://github.com/GitoxideLabs/gitoxide
> The unsafe versions of these things literally throw out history and replace it with a fiction that whoever did the final operation wrote everything, or that the original author wrote something possibly very divergent from what they actually wrote.
When I'm rebasing my own work and editing history, that's exactly what I'm looking to accomplish, though.
When I'm rebasing my own work and editing history, that's exactly what I'm looking to accomplish, though.
The team I work for tends to use GitHub's "Squash and merge" button a lot. I find it to be the best of both worlds: the `develop` branch gets a single commit per PR, with a summary of what was done (I always edit the summary commit message and reduce it from a copy of 20 commit messages down to just the most important 4-5, deleting the entirety of messages like "fixup" or "address review comments"). But the PR on GitHub also preserves the history of the commits, so anyone who wants to look at the messy commit history can follow the PR link and see the actual commits.
I'm sure there are other Git forges that would support a similar workflow, with a "Squash and Merge" button or equivalent, but my team hasn't felt any need to migrate away from GitHub so I've never yet investigated that in detail.
Only downside I've found to this workflow is that it would make it harder to migrate to a different Git forge in the future: unless you're very careful with the migration, the PR numbers are likely to be different (perhaps resetting at 1, even) and the other forge won't end up with the commits that are on GitHub's copy of the repo but no longer on any active branch (we also use the "auto-delete branches when you hit the merge button" option). But it would still be possible for a migration tool to handle this correctly: look at all PRs on GitHub, grab the commits from them, and migrate them to Merge Requests on the new forge.
I'm sure there are other Git forges that would support a similar workflow, with a "Squash and Merge" button or equivalent, but my team hasn't felt any need to migrate away from GitHub so I've never yet investigated that in detail.
Only downside I've found to this workflow is that it would make it harder to migrate to a different Git forge in the future: unless you're very careful with the migration, the PR numbers are likely to be different (perhaps resetting at 1, even) and the other forge won't end up with the commits that are on GitHub's copy of the repo but no longer on any active branch (we also use the "auto-delete branches when you hit the merge button" option). But it would still be possible for a migration tool to handle this correctly: look at all PRs on GitHub, grab the commits from them, and migrate them to Merge Requests on the new forge.
It boggles my mind that instead of this being a UI projection, git instead ingrains a process where developers habitually destroy their history (and bisection options, and merge conflict resolution), therein loading an additional footgun that goes off every now and again when it turns out a now-squashed branch was the basis of (or merged into) some other branch
It’s important to note that not all history is worth keeping, and keeping a dozen commits titled “fix” fixing build / CI errors from the original changes are a lot worse for bisecting than squashing it all into just one.
I very much prefer keeping histories by default (both my personal workflows and the tools I build default to that) but squash is a valuable tool.
I very much prefer keeping histories by default (both my personal workflows and the tools I build default to that) but squash is a valuable tool.
> keeping a dozen commits titled “fix” fixing build / CI errors from the original changes are a lot worse for bisecting than squashing it all into just one.
How so? When I bisect I want to get down to a small diff, landing on a stretch of several commits (because some didn't build) is still better than landing on a big squashed commit that includes all those changes and more. The absolute worst case when you keep the original history is the same as the default case when you squash.
How so? When I bisect I want to get down to a small diff, landing on a stretch of several commits (because some didn't build) is still better than landing on a big squashed commit that includes all those changes and more. The absolute worst case when you keep the original history is the same as the default case when you squash.
Because they’re broken and their only purpose is to fix up the original change, so it’s functionally the same change.
> The absolute worst case when you keep the original history is the same as the default case when you squash.
No, now you have a bunch of worthless broken commits that you need to evaluate and skip because they’re not the problem you’re looking for.
> The absolute worst case when you keep the original history is the same as the default case when you squash.
No, now you have a bunch of worthless broken commits that you need to evaluate and skip because they’re not the problem you’re looking for.
> Because they’re broken and their only purpose is to fix up the original change, so it’s functionally the same change.
Do you restrict yourself to 1 non-broken commit per PR? I don't, and nor does anyone I've worked with. If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win. (If you didn't care about that sort of thing you wouldn't be bisecting at all).
> No, now you have a bunch of worthless broken commits that you need to evaluate and skip because they’re not the problem you’re looking for.
What are you "evaluating"? If you want to ignore the individual commits and just look at the overall diff that's easy. If you want to ignore the individual messages and just look at the PR-time message that's easy too. Better to have the extra details and not need them than need them and not have them.
Do you restrict yourself to 1 non-broken commit per PR? I don't, and nor does anyone I've worked with. If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win. (If you didn't care about that sort of thing you wouldn't be bisecting at all).
> No, now you have a bunch of worthless broken commits that you need to evaluate and skip because they’re not the problem you’re looking for.
What are you "evaluating"? If you want to ignore the individual commits and just look at the overall diff that's easy. If you want to ignore the individual messages and just look at the PR-time message that's easy too. Better to have the extra details and not need them than need them and not have them.
> Do you restrict yourself to 1 non-broken commit per PR?
No. To the extent that I can however I do restrict myself to only non-broken commits.
> If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win
It is not a significant win when the bisecting session keeps landing me in your broken commits that I have to waste time evaluating and skipping.
And splitting out fixups doesn’t save anything (let alone “half the size”), most commonly those fixups are just modifying content the previous commits were touching already, so you’re increasing the total diff size you have to evaluate.
> What are you "evaluating"?
Whether the commit is the one that caused the issue I’m bisecting for.
> If you want to ignore the individual commits and just look at the overall diff that's easy. If you want to ignore the individual messages and just look at the PR-time message that's easy too.
Neither of these is true. git bisect (run) lands me on a commit, it’s broken, now I need to look whether the commit is broken in a way that is relevant to what I’m seeking.
> Better to have the extra details and not need them than need them and not have them.
Garbage is “extra details” only in the hoarder sense.
No. To the extent that I can however I do restrict myself to only non-broken commits.
> If there were even 2 non-broken commits in the PR, then bisecting with the original history lands you on a diff half the size that bisecting with squashed history would, which is a significant win
It is not a significant win when the bisecting session keeps landing me in your broken commits that I have to waste time evaluating and skipping.
And splitting out fixups doesn’t save anything (let alone “half the size”), most commonly those fixups are just modifying content the previous commits were touching already, so you’re increasing the total diff size you have to evaluate.
> What are you "evaluating"?
Whether the commit is the one that caused the issue I’m bisecting for.
> If you want to ignore the individual commits and just look at the overall diff that's easy. If you want to ignore the individual messages and just look at the PR-time message that's easy too.
Neither of these is true. git bisect (run) lands me on a commit, it’s broken, now I need to look whether the commit is broken in a way that is relevant to what I’m seeking.
> Better to have the extra details and not need them than need them and not have them.
Garbage is “extra details” only in the hoarder sense.
> It is not a significant win when the bisecting session keeps landing me in your broken commits that I have to waste time evaluating and skipping.
Skipping a commit that doesn't build is trivial (especially if you're automating your bisects).
> And splitting out fixups doesn’t save anything (let alone “half the size”), most commonly those fixups are just modifying content the previous commits were touching already, so you’re increasing the total diff size you have to evaluate.
If you feel the need to rebase to squash one-liner fixups into the commits they fix then that's a more subtle tradeoff and there are reasonable arguments. But squashing your whole PR for the sake of that is massive overkill, and the costs outweigh the benefits.
Skipping a commit that doesn't build is trivial (especially if you're automating your bisects).
> And splitting out fixups doesn’t save anything (let alone “half the size”), most commonly those fixups are just modifying content the previous commits were touching already, so you’re increasing the total diff size you have to evaluate.
If you feel the need to rebase to squash one-liner fixups into the commits they fix then that's a more subtle tradeoff and there are reasonable arguments. But squashing your whole PR for the sake of that is massive overkill, and the costs outweigh the benefits.
> Skipping a commit that doesn't build is trivial (especially if you're automating your bisects).
A broken commit usually compiles, if you don’t even compile before committing you should go back to school.
> If you feel the need to rebase to squash one-liner fixups into the commits they fix then that's a more subtle tradeoff and there are reasonable arguments. But squashing your whole PR for the sake of that
It would really have helped if you’d stated upfront that you can’t read.
A broken commit usually compiles, if you don’t even compile before committing you should go back to school.
> If you feel the need to rebase to squash one-liner fixups into the commits they fix then that's a more subtle tradeoff and there are reasonable arguments. But squashing your whole PR for the sake of that
It would really have helped if you’d stated upfront that you can’t read.
Yes, a good Git log viewer that would auto-squash branches down to a summary, and allow "expanding" them, would be useful. But the way branching and merging creates confusing train-track graphs is IMHO one of the reasons why many teams end up using the squash-and-merge workflow. There's definitely room for improvement there...
For sure. It just bugs me that we're stuck between two bad options.
Now let's also talk about renames...
Now let's also talk about renames...
I would assume most people who would enable an "auto squash" option also aren't carefully creating and curating commits. Bisect is useless if half your commits are broken. People regularly make commits that don't even build, much less pass QA and deliver a valid version of the software. These are works in progress, broken versions and should be deleted.
If you actually do like to deliver the correct number of commits then it's frustrating to work with people who don't care. In that case I would suggest making the squash optional but you could also try selling your team on doing smaller commits. In my experience you either "get it" or you don't, though. I've never successfully got someone to understand small commits.
If you actually do like to deliver the correct number of commits then it's frustrating to work with people who don't care. In that case I would suggest making the squash optional but you could also try selling your team on doing smaller commits. In my experience you either "get it" or you don't, though. I've never successfully got someone to understand small commits.
> I would assume most people who would enable an "auto squash" option also aren't carefully creating and curating commits.
Or don't have a choice. Our department-wide rules were almost to require that for all repos, I had to push hard just to make it "strongly suggested" instead.
Or don't have a choice. Our department-wide rules were almost to require that for all repos, I had to push hard just to make it "strongly suggested" instead.
Git doesn't do that. People needlessly destroying history do that.
Git will happily let you merge branches and preserve the history there. GP seems to like that history being in PRs only on github instead. I don't get why, that just seems worse to me.
Git will happily let you merge branches and preserve the history there. GP seems to like that history being in PRs only on github instead. I don't get why, that just seems worse to me.
The why is that most people when given the merge option don’t clean up their history so you end up with tons of garbage fix up commits.
That is an issue of ignorance, not laziness. It’s not obvious at all to an average developer that only uses `add/commit/merge/fetch/push/pull/rebase/restore/reset` that they can manipulate their change history.
The cause stops mattering after a while, either you have to go on a full time campaign to educate people… or switch the setting to rebase and squash and be done with it.
I've read much of the HN discussion on the previous post, a skimmed the rest, but I didn't see a couple of things addressed:
First, how could you make this deal with copies and renames? It seems to me like the pure version of this would require a weave of your whole repository.
Second, how different is this from something like jujutsu? As in, of course it's different, your primary data structure is a weave. But jj keeps all of the old commits around for any change (and prevents git from garbage collecting them by maintaining refs from the op log). So in theory, you could replay the entire history of a file at a particular commit by tracing back through the evolog. That, plus the exact diff algorithm, seems like enough to recreate the weave at any point in time (well, at any commit), and so you could think of this whole thing as a caching layer on top of what jj already provides. I'm not saying you would want to implement it like that, but conceptually I don't see the difference and so there might be useful "in between" implementations to consider.
In fact, you could even specify different diff algorithms for different commits if you really wanted to. Which would be a bit of a mess, because you'd have to store that and a weave would be a function of those diff algorithms and when they were used, but it would at least be possible. (Cohen's system could do this too, at the cost of tracking lots of stuff that currently it doesn't need or want to track.) I'm skeptical that this would be useful except in a very limited sense (eg you could switch diff algorithms and have all new commits use the new one, without needing to rebuild your entire repository). It breaks distributed scenarios -- everyone has to agree on which diff to use for each commit. It's just something that falls out of having the complete history available.
I'm cheating with jj a bit here, since normally you won't be pushing the evolog to remotes so in practice you probably don't have the complete history. In practice, when pushing to a remote you might want to materialize a weave or a weave-like "compiled history" and push that too/instead, just like in Cohen's model, if you really wanted to do this. And that would come with limitations on the diff used for history-less usage, since the weave has to assume a specific deterministic diff.
First, how could you make this deal with copies and renames? It seems to me like the pure version of this would require a weave of your whole repository.
Second, how different is this from something like jujutsu? As in, of course it's different, your primary data structure is a weave. But jj keeps all of the old commits around for any change (and prevents git from garbage collecting them by maintaining refs from the op log). So in theory, you could replay the entire history of a file at a particular commit by tracing back through the evolog. That, plus the exact diff algorithm, seems like enough to recreate the weave at any point in time (well, at any commit), and so you could think of this whole thing as a caching layer on top of what jj already provides. I'm not saying you would want to implement it like that, but conceptually I don't see the difference and so there might be useful "in between" implementations to consider.
In fact, you could even specify different diff algorithms for different commits if you really wanted to. Which would be a bit of a mess, because you'd have to store that and a weave would be a function of those diff algorithms and when they were used, but it would at least be possible. (Cohen's system could do this too, at the cost of tracking lots of stuff that currently it doesn't need or want to track.) I'm skeptical that this would be useful except in a very limited sense (eg you could switch diff algorithms and have all new commits use the new one, without needing to rebuild your entire repository). It breaks distributed scenarios -- everyone has to agree on which diff to use for each commit. It's just something that falls out of having the complete history available.
I'm cheating with jj a bit here, since normally you won't be pushing the evolog to remotes so in practice you probably don't have the complete history. In practice, when pushing to a remote you might want to materialize a weave or a weave-like "compiled history" and push that too/instead, just like in Cohen's model, if you really wanted to do this. And that would come with limitations on the diff used for history-less usage, since the weave has to assume a specific deterministic diff.
You can generically represent copies and renamed (aka "moves") in a CRDT, OT or CTM using a Portal: https://braid.org/meeting-62/portals
usually the whole discussion has been around line-level vs commit-level history, but there's a layer nobody's talking about, and I have been exploring it here these days with https://github.com/Ataraxy-Labs/sem. It gives you entity-level version control. It parses your code into functions, classes, methods using tree-sitter (12 languages so far), computes a structural hash for each entity, and builds a cross-file dependency graph. So sem diff HEAD~1 doesn't give you "+3 -2 in tax.py", it gives you "calculate_tax signature changed, 47 dependents, 3 callers will break". The key insight is distinguishing signature changes from body changes.
> Git is very simple, reliable, and versatile, but it isn’t very functional.
Funny, I would probably swap the first and the last adjective in that sentence.
Funny, I would probably swap the first and the last adjective in that sentence.
Git, the internals, are simple, but not very functional.
Git, the porcelain, isn't simple, is quite functional.
> Oddly they don’t seem to have figured out the generation counting trick, which is something I did come up with over twenty years ago. Combining the two ideas is what allows for there to be no reference to commit ids in the history and have the entire algorithm be structural.
Can you say more about this? What exactly is this trick you’re talking about? What are the benefits?
Can you say more about this? What exactly is this trick you’re talking about? What are the benefits?
Not the OP, but probably this: https://tonyg.github.io/revctrl.org/GenerationCounting.html
(That seems to be an archive of the old revctrl.org pages from a while back; most likely Bram Cohen has a blog somewhere explaining it in his own words - probably about 2003, at a guess)
(That seems to be an archive of the old revctrl.org pages from a while back; most likely Bram Cohen has a blog somewhere explaining it in his own words - probably about 2003, at a guess)
https://github.com/bramcohen/manyana?tab=readme-ov-file#why-...
But someone may need to explain it to me.
But someone may need to explain it to me.
Discussion on the previous post in this series: https://news.ycombinator.com/item?id=47478401
Someone make a TLA+ model for this bad boy
I for my part have not migrated to GIT cause i do not need the extra hoops like staging area or syncing whole repos over network. I have always a server at my side and can work with checkout/checkin. This implies a hard requirement at interface definitions, cause people can't just alter them. Seeing people struggle with all the problems introduced with the git way of work I feel there is still a big market for not git. People are introduced to git and stop asking if there isn't something more good to there workfow. Excuse my english please, im a non native speaker
At least jj tries to fix this partly, and I feel like its good enough for what I do. Most of my projects nowadays are solo, so I can keep it simple.
Git is a decentralized version control system. Creating a new project is just a `git init` away.
Of course centralized VCS are less popular. You need to setup a server first then wrangle with the server every time you create a new project -> fewer projects -> fewer users.
Of course centralized VCS are less popular. You need to setup a server first then wrangle with the server every time you create a new project -> fewer projects -> fewer users.
For instance Pijul might very well be a lot better than git / jj. I wouldn't know, I haven't bothered trying it because all the projects I need to work in use git. But since jj has great git compatibility, I actually have been able to adopt it because of its git backend.
A new VCS that doesn't have git compatibility at its core is going to have a really hard time overcoming network effects.