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

61–70 of 407 posts

Re: The future of version control

#61

Post by layer8 »

mikey-k wrote: post #10

Interesting idea. While conflicts can be improved, I personally don't see it as a critical challenge with VCS. What I do think is the critical challenge (particularly with Git) is scalability. Size of repository & rate of change of repositories are starting to push limits of git, and I think this needs revisited across the server, client & wire protocols. What exactly, I don't know. :). But I do know that in my curre…

One solution is to decompose your code into modules with stable interfaces and reference them as versioned dependencies.

Re: The future of version control

#62

Post by jwilliams »

layer8 wrote: post #45
jwilliams wrote: post #44

Earlier quoted context omitted.

Indeed. And plenty of successful merges end up with code that won't compile. FWIW I've struggled to get AI tools to handle merge conflicts well ( especially rebase ) for the same underlying reason.

Code not compiling is still the good case, because you’ll notice before deployment. The dangerous cases are when it does compile.

Very true.

I realized recently that I've subconsciously routed-around merge conflicts as much as possible. My process has just subtly altered to make them less likely. To the point of which seeing a 3-way merge feels jarring. It's really only taking on AI tools that bought this to my attention.

Re: The future of version control

#63

Post by vova_hn2 »

ZoomZoomZoom wrote: post #4

The key insight in the third sentence? > ... CRDTs for version control, which is long overdue but hasn’t happened yet Pijul happened and it has hundreds - perhaps thousands - of hours of real expert developer's toil put in it. Not that Bram is not one of those, but the post reads like you all know what.

I have a weird hobby: about once a year I go to the theory page [0] in pijul manual and see if they have fixed the TeX formatting yet.

You would think that if a better, more sound model of storing patches is your whole selling point, you would want to make as easy as possible for people who are interested in the project to actually understand it. It is really weird not to care about the first impression that your manual makes on a curious reader.

Currently, I'm about 6 years into the experiment.

Approximately 2 years in (about 4 years ago), I've actually went to the Pijul Nest and reported [1] the issue. I got an explanation on fixing this issue locally, but weirly enough, the fix still wasn't actually implemented on the public version.

I'll report back in about a year with an update on the experiment.

[0] https://pijul.org/manual/theory.html

[1] https://nest.pijul.com/pijul/manual/discussions/46

Re: The future of version control

#64

Post by ericpauley »

rightbyte wrote: post #59
conradludgate wrote: post #51

Earlier quoted context omitted.

My understanding of the way this is presented is that merges don't _block_ the workflow. In git, a merge conflict is a failure to merge, but in this idea a merge conflict is still present but the merge still succeeds. You can commit with conflicts unresolved. This allows you to defer conflict resolution to later. I believe jj does this as well? Technically you could include conflict markers in your commits but I don'…

> You can commit with conflicts unresolved. True but it is not valid syntax. Like, you mean with the conflict lines?

Yeah this seems silly. You can do the same thing in git (add and commit with the conflict still there)! Why you would want to is a real mystery.

Re: The future of version control

#65

Post by zahlman »

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.

Re: The future of version control

#66

Post by roryokane »

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 the logging line.

Re: The future of version control

#68

Post by jayd16 »

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.

Totally agree. After trying to flesh out Unreal's git plugin, it really shows how far from ideal git really is.

Partial checkouts are awkward at best, LFS locks are somehow still buggy and the CLI doesn't support batched updates. Checking the status of a remote branch vs your local (to prevent conflicts) is at best a naive polling.

Better rebase would be a nice to have but there's still so much left to improve for trunk based dev.

Re: The future of version control

#70

Post by ktm5j »

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'm on my phone right now so I'm not going to dig too hard for this, but you can also configure a "merge tool" (or something like that) so you can use Meld or Kompare to make the process easier. This has helped me in a pinch to work out some confusing merge conflicts.
Post reply on HN