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

351–360 of 407 posts

Re: The future of version control

#351

Post by bilekas »

m12k wrote: post #347

I used to think the future of version control was semantic: E.g. I renamed a method, while someone else concurrently added another call to that (now differently named) method. Git doesn't catch this, nor would this new system. The solution seems obvious to a human: Use the new name at the new call-site too. But it requires operating at the level of the semantic meaning of a change, and not just the dumb textual chang…

This is more than just a version control though, they only thing any VC uses that's important is the diff and the timestamps, you would be adding in project context awareness which is a whole other thing.

I'm sure there are smarter people than me who could create some hooks to automagically update those references on merge/rebase though. Not sure I would pay a whole LLM each time personally.

Re: The future of version control

#352

Post by commandersaki »

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.

Is there any FOSS tool that gives a 4-pane merge, or even 3-pane so long as the third pane would show the resulting change. That would be so handy.

Re: The future of version control

#353

Post by WolfeReader »

m12k wrote: post #347

I used to think the future of version control was semantic: E.g. I renamed a method, while someone else concurrently added another call to that (now differently named) method. Git doesn't catch this, nor would this new system. The solution seems obvious to a human: Use the new name at the new call-site too. But it requires operating at the level of the semantic meaning of a change, and not just the dumb textual chang…

Darcs did this decades ago with the "replace" command. It's not a legitimate semantic replacement, though - it's more just telling your VCS to do a find/replace.

Re: The future of version control

#354

Post by WolfeReader »

nailer wrote: post #326
dcre wrote: post #193

Earlier quoted context omitted.

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

Thanks for the correct link! AST-based version control sounds like a great idea.

Re: The future of version control

#355

Post by jayd16 »

samuelstros wrote: post #91
lifeformed wrote: post #13

My issue with git is handling non-text files, which is a common issue with game development. git-lfs is okay but it has some tricky quirks, and you end up with lots of bloat, and you can't merge. I don't really have an answer to how to improve it, but it would be nice if there was some innovation in that area too.

Improving on "git not handling non-text files" is a semantic understanding aka parse step in between the file write. Take a docx, write the file, parse it into entities e.g. paragraph, table, etc. and track changes on those entities instead of the binary blob. You can apply the same logic to files used in game development. The hard part is making this fast enough. But I am working on this with lix [0]. [0] https://gi…

What's the plan for large files that can't be merged? Images, executable binaries, encrypted files, that sort of thing?

Re: The future of version control

#356

Post by verdverm »

adastra22 wrote: post #281
verdverm wrote: post #218

Earlier quoted context omitted.

Similarly, CUE uses Gerrit and has two way sync. If you are building a VCS today, git interop is a must.

What if the whole point of your VCS is that it its core data structure is nothing like git's at all?

As a user, why do I care how the internals work?

What I do care about is an easy path to progressive adoption and migration. Without that, I cannot convince my team / org to force everyone over.

Re: The future of version control

#357

Post by furyofantares »

theK wrote: post #286
furyofantares wrote: post #71

Earlier quoted context omitted.

The conflict lines shown in the article are not present in the file, they are a display of what has already been merged. The merge had changes that were too near each other and so the algorithm determined that someone needs to review it, and the conflict lines are the result of displaying the relevant history due to that determination. In the example in the article, the inserted line from the right change is floating…

Isnt that a bit dangerous in its own? If the merge process can complete without conflicts being resolved, doesnt it just push the Problem down the road? All of a sudden you have to deal with failing CI or ghost features that involve multiple people where actually you just should has solved you conflict locally at merge time.

The tooling can force resolution at any step desired.

Re: The future of version control

#358

Post by wakawaka28 »

psychoslave wrote: post #350
wakawaka28 wrote: post #210

Earlier quoted context omitted.

>Maybe "local/alien" might be a less pompous vocabulary to convey the same idea. That is more alien and just as contrived. If you merge branches that you made, they're both local and "ours". You just have to remember that "ours" is the branch you are on, and "theirs" is the other one. I have no idea what happens in an octopus merge but anyway, the option exists to show commit titles along with markers to help you kee…

Indeed, thanks. Something that carry the meaning "the branch we want to use as a starting point" and "the other branch we want to integrate in the previous one" is what I had in mind, but it might not fit all situations in git merge/rebase.

Assuming you have to start on one of the branches being merged, "current" is a good name for the one you started on. "Other" is good enough for the other one. By the way I found out that octopus merges never succeed in case of conflicts. I'm not even sure if prerecorded resolutions work in that case. You're supposed to do a series of normal merges instead if you have conflicts.

Re: The future of version control

#359

Post by jayd16 »

zahlman wrote: post #65
lifeformed wrote: post #13

My issue with git is handling non-text files, which is a common issue with game development. git-lfs is okay but it has some tricky quirks, and you end up with lots of bloat, and you can't merge. I don't really have an answer to how to improve it, but it would be nice if there was some innovation in that area too.

What strategies would you like to use to diff the binaries? Or else how are you going to avoid bloat? Is it actually okay to try to merge changes to binaries? If two people modify, say, different regions of an image file (even in PNG or another lossless compression format), the sum of the visual changes isn't necessarily equal to the sum of the byte-level changes.

The best solution I've seen is prevention.

What you can do in P4 is work in trunk, make sure you have latest and lock binary files you're working on. If you do that you won't have conflicts (at the file level anyway). Unlike git's design, this collaborative model is centralized and synchronous but it works.

Git is missing the built in binary support, the locking, and the efficient information sharing of file status tracking. With LFS you can cobble something together but it's not fast or easy.

I'm all for other solutions but I wish git would at least support this flow more whole heartedly until something else is invented.

Post reply on HN