Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of version control

bramcohen.com

Post reply on HN
Print view View original

321–330 of 407 posts

Re: The future of version control

#321

Post by gf000 »

ivlozada wrote: post #288
josephg wrote: post #163

Earlier quoted context omitted.

CRDTs should be able to give you better merge and rebase behaviour. They essentially make rebase and merge commits the same thing - just different views on a commit, and potentially different ways to present the conflict. CRDTs also behave better when commits get merged multiple times in complex graphs - you don’t run into the problem of commits conflicting with themselves. You should also be able to roll back a sing…

This is the key point. Once your data structure carries the full edit history instead of reconstructing it from DAG traversal, rebase and merge become different views of the same operation. Not fundamentally different operations with different failure modes. The weave approach moves ordering into the data itself. That's the same insight that matters in any system that needs deterministic ordering across independent p…

Afaik pijul already does that though

Re: The future of version control

#323

Post by tempodox »

roryokane wrote: post #66
ulrikrasmussen wrote: post #19

The thing about how merges are presented seems orthogonal to how to represent history. I also hate the default in git, but that is why I just use p4merge as a merge tool and get a proper 4-pane merge tool (left, right, common base, merged result) which shows everything needed to figure out why there is a conflict and how to resolve it. I don't understand why you need to switch out the VCS to fix that issue.

Even if you don’t use p4merge, you can set Git’s merge.conflictStyle config to "diff3" or "zdiff3" ( https://git-scm.com/docs/git-config#Documentation/git-config... ). If you do that, Git’s conflict markers show the base version as well: >>>>>> right With this configuration, a developer reading the raw conflict markers could infer the same information provided by Manyana’s conflict markers: that the right side added…

I still find this shit unreadable, even after years of practice.

Re: The future of version control

#324

Post by andy_ppp »

ralferoo wrote: post #225
KPGv2 wrote: post #215

Earlier quoted context omitted.

> Git generally works better without rebases and squash commits. If squash commits make Git harder for you, that's a tell that your branches are trying to do too many things before merging back into main.

I don't know. Even when I'm working on my own private repositories across several machines, I really, really dislike regular merges. You get an ugly commit message and I can never get git log to show me the information I actually want to see. For me, rebasing is the simplest and easiest to understand, and it allows you to squash some of your commits so that it's one commit per feature / bug-fix / logical unit of work…

I completely agree, since doing rebase our history looks fantastic and it makes finding things, cherrypicking and generating changelogs really simple. Why not be neat, it's cost us nothing and you can make yourself a tutorial on Claude if you don't understand rebasing pretty easily.

Re: The future of version control

#325

Post by andy_ppp »

KPGv2 wrote: post #215
sheept wrote: post #202

Earlier quoted context omitted.

"Ours" and "theirs" make sense in most cases (since "ours" refers to the HEAD you're merging into). Rebases are the sole exception (in typical use) because ours/theirs is reversed, since you're merging HEAD into the other branch. Personally, I prefer merge commits over rebases if possible; they make PRs harder for others to review by breaking the "see changes since last review" feature. Git generally works better wit…

> Git generally works better without rebases and squash commits. If squash commits make Git harder for you, that's a tell that your branches are trying to do too many things before merging back into main.

Don't do squash commits, just rebase -i your branch before merging so you only have one commit. It's pretty trivial to do.

Re: The future of version control

#326

Post by nailer »

dcre wrote: post #193
nailer wrote: post #191

You’re still treating code as text which it isn’t (in the same way you wouldn’t treat JSON as text) it’s actually more like an AST. Jujutsi (jj) does that. And it’s git compatible.

I love jj and think virtually every git user should switch to it, but I don't think it treats text as an AST. What do you mean?

Ugh you're right. There was a new AST-based version control system that came out a month ago and I couldn't remember the name. I asked an LLM what the name was and repeated the answer the LLM gave me without checking (facepalm).

I may have been thinking of https://github.com/gritzko/librdx/tree/master/be

Re: The future of version control

#327

Post by goku12 »

kungito wrote: post #85
psychoslave wrote: post #76

Earlier quoted context omitted.

That still have an issue with the vocabulary. Things like "theirs/our" is still out of touch but it's already better than a loose spatial analogy on some representation of the DAG. Something like base, that is "common base", looks far more apt to my mind. In the same vein, endogenous/exogenous would be far more precise, or at least aligned with the concern at stake. Maybe "local/alien" might be a less pompous vocabul…

After 15 years i still cant remember which is which. I get annoyed every time. Maybe I should invest 15 minutes finally to remember properly

I was thinking about creating a TUI application that points out what each part in the conflict indicator corresponds to. This idea is primarily meant for rebases where the HEAD and the ID of the updated commits change constantly. Think of it as a map view of the rebase process, that improves your situational awareness by presenting all the relevant information simultaneously. That could trivially work for merges too.

Re: The future of version control

#328

Post by goku12 »

KPGv2 wrote: post #211
sheept wrote: post #198

Earlier quoted context omitted.

doesn't it? Next to the conflict markers, it'll display HEAD, the ref name, or the short commit hash.

I'll be honest, as a fairly skilled and experienced programmer who isn't a git expert, I know what HEAD means, but when I'm rebasing I really have no idea. It all seems to work out in the end because my collaborative work is simple and usually 2–3 people only, so I'm never rebasing against a ton of commits I lack context for (because 90% of them are my commits since I'm usually dealing with PRs to my open source proj…

> HEAD is "the thing we're editing now" but that's not terribly useful when rebasing since you're repeatedly editing a fake history.

You got two things wrong here. Firstly, HEAD isn't 'the thing you're editing now'. HEAD is what you have already committed. If you want to edit the HEAD, you have to either amend the commit or reset and redo the commit. (To make the situation even more complex, the amended or overridden commit remains in the repo unchanged, but orphaned.)

The actual thing being edited is a 'patch' that will eventually be converted into a new commit (snapshot). If you're doing a rebase and want to see the next patch in the pipeline that you're editing now, try this:

  git rebase --show-current-patch
Secondly, rebase is not editing a fake history. Rebase is creating a new (and real) history by repeatedly cherry picking commits from the old history based on the rebase plan. HEAD is the tip commit of the new history under construction. On completion of the rebase, the branch ref of the old history is switched to the new history, where HEAD is now at. Meanwhile, the old history remains in the repo unchanged, but again orphaned.

All the orphaned commits are still visible in the HEAD's reflog. You can use it to undo the rebase if you wish.

I agree that the entire thing is confusing as hell. But I have a bunch of aliases and scripts that show you the process graphically in realtime. You can use that awareness to make the right call every time. I'm thinking about converting it into a TUI application and publishing it.

Re: The future of version control

#329

Post by mtndew4brkfst »

afiori wrote: post #216
sroussey wrote: post #180

Earlier quoted context omitted.

In theory, maybe. In practice… last write wins (LWW) is a CFDT operator, so replace every mention of CRDT with LWW and issues will more obvious. Really though, the problem with merges is not conflicts, it’s when the merged code is wrong but was correct on both sides before the merge. At least a conflict draws your attention. When I had several large (smart but young) teams merging left and right this would come up an…

being able to customize the chunking/diffing process with something analogous to an lsp would greatly improve this. In my experience a particularly horribly handled case is when eg two branches add two distinct methods/functions in the same file location (especially if there is some boilerplate so that the two blocks share more than a few lines). a language aware merge could instead produce >>>> function foo(){ ... }…

If you haven't heard of it yet, Mergiraf uses tree-sitter grammars to resolve merges using syntax-aware logic and has a pretty good success rate for my work.

Re: The future of version control

#330

Post by mpalmer »

This sounds more like the present of version control in the form of Jujutsu, which already supports 3-way merges and history-preserving rebases, and does so with data structures that are trivially representable in a standard git repo.

> What it is is a proof that CRDT-based version control can handle the hard UX problems and come out with better answers than the tools we’re all using today — and a coherent design for building the real thing.

No such thing is "proven". You have not proven superiority to the state of the art with 400 lines of Python.

The LLM you used to draft this blog post is making your solution out to be far more than it is at this point.

Post reply on HN