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

401–407 of 407 posts

Re: The future of version control

#401

Post by shaftway »

recursivecaveat wrote: post #20
radarsat1 wrote: post #5

Is it a good thing to have merges that never fail? Often a merge failure indicates a semantic conflict, not just "two changes in the same place". You want to be aware of and forced to manually deal with such cases. I assume the proposed system addresses it somehow but I don't see it in my quick read of this.

It says that merges that involve overlap get flagged to the user. I don't think that's much more than a defaults difference to git really. You could have a version of git that just warns on conflict and blindly concats the sides.

This is kind of how jj handles the situation. git won't let you move on from a rebase if there are conflicts. By comparison, jj will just put a marker in the log pointing out that there are conflicts in a branch. You resolve them whenever you feel like it, but all resolving them does is effectively remove the "conflict" marker and rebase all of the descendent commits (which may clean up merge conflicts, or make them worse).

Re: The future of version control

#402

Post by shaftway »

anentropic wrote: post #308
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'…

If other systems are doing it too then I guess it must be useful But why is it useful to be able to defer conflict resolution? I saw in a parallel comment thread people discussing merge commit vs rebase workflow - rebase gives cleaner git history but is a massive pain having to resolve conflicts on every commit since current branch diverged instead of just once on the final result with merge commit. Is it that? Defer…

Delayed conflict resolution in jj is valuable when you're rebasing a long chain of commits. If I rebase a chain of 10 commits and each of the commits has a conflict, I'm stuck in conflict resolution mode until I fix all 10 conflicts. Maybe something else came up, or maybe I got tired of doing conflict resolution and want to do something else. Git's answer is to finish or abandon.

Also, in jj it's pretty easy to rebase a lot of stuff all at once, giving you even more opportunities to create conflicts. Being able to delay resolution can be easier.

Re: The future of version control

#403

Post by shaftway »

furyofantares wrote: post #376
theK wrote: post #364

Earlier quoted context omitted.

What's the point of options when there only is one correct answer?

The conflict is no longer an ephemeral part of the merge that only ever lives as markup in the source files and is stomped by the resolution that's picked, but instead a part of history. I think it is also not true that there's only one correct answer, although I don't know how valuable this is. For committing let's say yes, only one correct answer. Say the tool doesn't let you commit after you've merged without reso…

> The conflict is no longer an ephemeral part of the merge that only ever lives as markup in the source files and is stomped by the resolution that's picked, but instead a part of history.

How is this different than having a merge commit?

Re: The future of version control

#404

Post by sebmellen »

ulrikrasmussen wrote: post #393
sebmellen wrote: post #208

Earlier quoted context omitted.

Wow, interesting to see such a diametrically opposed view. We’ve banned merge commits internally and our entire workflow is rebase driven. Generally, I find that rebases are far better at keeping Git history clean and clearly allowing you to see the diff between the base you’re merging into and the changes you’ve made.

"Clean" is not the same as "useful". You have to be really, really disciplined to not make a superficially looking "clean" history which may appear linear but which is actually total nonsense. For example, if one is frequently doing "fix after rebase" commits, then they are doing it wrong and are making a history which is much less useful than a seemingly more complicated merge based history. Rebased histories are on…

Generally our pattern is that every PR gets rebased into sensible commits. So in a way we are doing "squash commits" but the method is an interactive rebase. This keeps our history very pretty and clean, and simultaneously easy to grok and navigate.

My favorite git GUI is Sublime Merge.

Re: The future of version control

#405

Post by lifeformed »

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.

I guess a good way to preview things would go a long way. Merging might be unrealistic to generalize, but being able to diff on images, game engine prefabs, audio, etc would help deciding which one to use.

Re: The future of version control

#406

Post by adastra22 »

verdverm wrote: post #399
adastra22 wrote: post #391

Earlier quoted context omitted.

It solves problems that you dont encounter if you are asking that question. I’ve lost a literal year or more of my life, in aggregate, to rebasing changes against upstream that could have been handled automatically by a sufficiently smart VCS.

An alternative explanation is that I already have a tool that helps me with these situations. The question was a bit rhetorical, because the vast majority of devs don't care what language many of their tools are written in or what algos are used. A different example, Go's MVS algo can be considered much better for dependency management. What are your thoughts on the SAT solver being replaced in your preferred languag…

If you have a tool for better rebasing, I’d love to hear it.
Post reply on HN