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

341–350 of 407 posts

Re: The future of version control

#341

Post by Ajedi32 »

sebmellen wrote: post #208
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…

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.

Yes, I prefer that approach as well because it allows the person who authored the change to do all the work of deciding how to resolve conflicts up front (and allows reviewers to review that conflict resolution) instead of forcing whoever eventually does the merge to figure everything out after the fact. It also removes conflicts from the history so you never have to think about them later after the rebase/merge process is finished.

Re: The future of version control

#342

Post by ithkuil »

mtndew4brkfst wrote: post #333
ithkuil wrote: post #119

Earlier quoted context omitted.

It clearly says in the article that this is just a demo

A demo as "the future of" something doesn't really resonate with me. It's like saying a melodic motif and a couple well-written lines of lyrics are "the future of" my new music career.

I guess it depends on how you parse "the future of X".

To me it sounds like "This is how I imagine the future of X", i.e. a preview of a possible future.

Re: The future of version control

#343

Post by sigbottle »

Retr0id wrote: post #188
tbrownaw wrote: post #178

Earlier quoted context omitted.

> You can't use CRDTs for version control You misunderstand what is being proposed. Using CRDTs to calculate the results of a merge does not require being allowed to commit the results of that calculation, and doesn't even require that you be able to physically realize the results in the files in your working copy. . Consider for example if you want to track and merge scalar values. Maybe file names if you track rena…

If semantics-layer conflicts still have to be detected somehow, and resolved by hand, what value is the underlying CRDT providing?

This was my immediate thought when seeing this post too lol.

Re: The future of version control

#345

Post by fransje26 »

IshKebab wrote: post #123
roryokane wrote: post #66

Earlier quoted context omitted.

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…

This is better but it still doesn't really help when the conflict is 1000 lines and one side changed one character and the other deleted the whole thing. That isn't theoretical - it happens quite regularly. What you really need is the ability to diff the base and "ours" or "theirs". I've found most different UIs can't do this. VSCode can, but it's difficult to get to. I haven't tried p4merge though - if it can do tha…

If I understood your point correctly, I believe that Meld can do that. And then you get a windows as [1]. You can configure git to choose which version goes where. Something like:

    [mergetool "meld"]                                                                                  
        cmd = meld "$LOCAL" "$MERGED" "$REMOTE" --output "$MERGED"                                      
        #cmd = meld "$LOCAL" "$BASE" "$REMOTE" --output "$MERGED"
[1] https://linuxkamarada.com/files/2019/11/git-mergetool-meld-e...

Re: The future of version control

#347

Post by m12k »

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 changes. I used to think this would require a new version control system that encodes the semantics of the changes in the commits, in order to have them available at merge-time. But these days, it seems much more realistic to stick to git, but loop in LLMs when merging, to re-create the semantics from the textual changes.

Re: The future of version control

#348

Post by radarsat1 »

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…

> Should you be counting on confusion of an underpowered text-merge to catch such problems?

This does not really follow from my statement.

I said that underpowered text merge should not silently accept such situations, not that it is the only way to catch them. It doesn't replace knowing something about what you are merging, but it is certainly a good hint that something may be wrong or unexpected.

> Post-merge syntax checks are better for that purpose.

Better, yes, but I was addressing semantic issues, not syntactical. I have seen syntactically valid merges result in semantic inconsistency, it does happen.

I do agree with your last statement.. unit & integration tests, agent checks or whathaveyou, these all contribute to semantic checking, which is a good thing.

Can they be relied on here? Maybe? I guess the jury is still out. My testing philosophy is "you can only test for what you think of testing". And tests and agent checks have a signal to noise ratio, and are only as useful as their SNR allows.

There is no guaranteed way to stop bugs from happening, if there were it likely would have been discovered by now. All we can do is take a layered approach to provide opportunities for them to get caught early. Removing one of those layers (merge conflicts) is not clearly a good thing, imho, but who knows.. if agent checks can replace it, then sure, I'm all for it.

Re: The future of version control

#349

Post by adastra22 »

simonw wrote: post #302
adastra22 wrote: post #280

Earlier quoted context omitted.

Git is not a protocol, it is a data format. That only makes sense when your VCS system is similar enough to git to easily allow converting between the two representations.

I mean things like git-svn, hg-git, git-p4, git-remote-fossil, git-tfs, jj.

Every single one of those is following variations on the exact same data structure, or is actually git in a trenchcoat.

Re: The future of version control

#350

Post by psychoslave »

wakawaka28 wrote: post #210
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…

>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.

Post reply on HN