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

41–50 of 407 posts

Re: The future of version control

#41

Post by jwr »

TacticalCoder wrote: post #28
crote wrote: post #24

Earlier quoted context omitted.

Seconding the use of p4merge for easy-to-use three-pane merging. Just like most other issues with Git, if your merges are painful it's probably due to terrible native UX design - not due to anything conceptually wrong with Git.

Thirding it except I do it from Emacs. Three side-by-side pane with left / common ancestor / right and then below the merge result. By default it's not like that but then it's Emacs so anything is doable. I hacked some elisp code a great many years ago and I've been using it ever since. No matter the tool, merges should always be presented like that. It's the only presentation that makes sense.

Isn't that what ediff does?

Re: The future of version control

#42

Post by skydhash »

MarsIronPI wrote: post #37
TacticalCoder wrote: post #28

Earlier quoted context omitted.

Thirding it except I do it from Emacs. Three side-by-side pane with left / common ancestor / right and then below the merge result. By default it's not like that but then it's Emacs so anything is doable. I hacked some elisp code a great many years ago and I've been using it ever since. No matter the tool, merges should always be presented like that. It's the only presentation that makes sense.

What tool do you use? Does Magit support it natively?

I think you need to enable 3 way merge by default in git's configuration, and both smerge (minor mode for solving conflicts) and ediff (major mode that encompass diff and patch) will pick it up. In the case of the latter you will have 4 panes, one for version A, another for version B, a third for the result C, and the last is the common ancestor of A and B.

Addendum: I've since long disabled it. A and B changes are enough for me, especially as I rebase instead of merging.

Re: The future of version control

#43

Post by simonw »

codethief wrote: post #17
simonw wrote: post #11

Earlier quoted context omitted.

I hadn't heard of Pijul. My first search took me to https://github.com/8l/pijul which hasn't been updated in 11 years, but it turns out that's misleading and the official repo at https://nest.pijul.com/pijul/pijul had a commit last month. ... and of course it is, because Pijul uses Pijul for development, not Git and GitHub!

> I hadn't heard of Pijul I'm surprised! Pijul has been discussed here on HN many, many times. My impression is that many people here were hoping that Pijul might eventually become a serious Git contender but these days people seem to be more excited about Jujutsu, likely because migration is much easier.

Looks like it makes the homepage only once or twice a year (using points>50 as a proxy for that), had more buzz around five years ago: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Re: The future of version control

#44

Post by jwilliams »

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.

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.

Re: The future of version control

#45

Post by layer8 »

jwilliams wrote: post #44
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.

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.

Re: The future of version control

#46

Post by lasgawe »

This is a really interesting and well thought out idea, especially the way it turns conflicts into something informative instead of blocking. The improved conflict display alone makes it much easier to understand what actually happened. I think using CRDTs to guarantee merges always succeed while still keeping useful history feels like a strong direction for version control. Looks like a solid concept!

Re: The future of version control

#48

Post by skydhash »

gojomo wrote: post #27
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.

Should you be counting on confusion of an underpowered text-merge to catch such problems? It'll fire on merge issues that aren't code problems under a smarter merge, while also missing all the things that merge OK but introduce deeper issues. Post-merge syntax checks are better for that purpose. And imminently: agent-based sanity-checks of preserved intent – operating on a logically-whole result file, without merge-t…

> It'll fire on merge issues that aren't code problems under a smarter merge, while also missing all the things that merge OK but introduce deeper issues.

That has not been my experience at all. The changes you introduced is your responsibility. If you synchronizes your working tree to the source of truth, you need to evaluate your patch again whether it introduces conflict or not. In this case a conflict is a nice signal to know where someone has interacted with files you've touched and possibly change their semantics. The pros are substantial, and it's quite easy to resolve conflicts that's only due to syntastic changes (whitespace, formatting, equivalent statement,...)

Re: The future of version control

#49

Post by a-dub »

doesn't the side by side view in github diff solve this?

conflict free merging sounds cool, but doesn't that just mean that that a human review step is replaced by "changes become intervals rather than collections of lines" and "last set of intervals always wins"? seems like it makes sense when the conflicts are resolved instantaneously during live editing but does it still make sense with one shot code merges over long intervals of time? today's systems are "get the patch right" and then "get the merge right"... can automatic intervalization be trusted?

edit: actually really interesting if you think about it. crdts have been proven with character at a time edits and use of the mouse select tool.... these are inherently intervalized (select) or easy (character at a time). how does it work for larger patches can have loads of small edits?

Re: The future of version control

#50

Post by dfhvneoieno »

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.

[dead]
Post reply on HN