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

241–250 of 407 posts

Re: The future of version control

#241

Post by itintheory »

KPGv2 wrote: post #212
IgorPartola wrote: post #97

Earlier quoted context omitted.

Let’s see if I get this wrong after 25 years of git: ours means what is in my local codebase. theirs means what is being merged into my local codebase. I find it best to avoid merge conflicts than to try to resolve them. Strategies that keep branches short lived and frequently merging main into them helps a lot.

> ours means what is in my local codebase Since it's always one person doing a merge, why isn't it "mine" instead of "ours"? There aren't five of us at my computer collaboratively merging in a PR. There is one person doing it. "Ours" makes it sound like some branch everyone who's working on the repo already has access to, not the active branch on my machine.

That's between you and git.

Re: The future of version control

#243

Post by mkj »

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.

Are you saying Bram hasn't worked on VCS problems much? https://web.archive.org/web/20071213090008/http://codeville.... is 20 years.

Re: The future of version control

#244

Post by arikrahman »

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.

The extensibility provided with Emacs Lisp has been helpful for hacking together my own Git/Jujutsu plugin. I tried to model it over lazygit/lazyjj although magit has been incredible to use and hard to depart from.

Re: The future of version control

#245

Post by IgorPartola »

bathwaterpizza wrote: post #173
IgorPartola wrote: post #162

Earlier quoted context omitted.

That is literally what I advocate you do for the main branch. A feature branch is allowed to have WIP commits that make sense for the developer working on the branch just like uncommitted code might not be self contained because it is WIP. Once the feature is complete, squash it into one commit and merge it into main. There is very little value to those WIP commits (rare case being when you implement algorithm X but…

One downside of squash merging is that when you need to split your work across branches, so that they're different PRs, but one depends on the other, then you have to do a rebase after every single one which had dependencies is merged.

When that happens I essentially pick one of the branches as the trunk for that feature and squash merge into that, test it, then merge a clean history into main.

Re: The future of version control

#247

Post by IgorPartola »

imiric wrote: post #223
IgorPartola wrote: post #97

Earlier quoted context omitted.

Let’s see if I get this wrong after 25 years of git: ours means what is in my local codebase. theirs means what is being merged into my local codebase. I find it best to avoid merge conflicts than to try to resolve them. Strategies that keep branches short lived and frequently merging main into them helps a lot.

> Let’s see if I get this wrong after 25 years of git You used it 5 years before Linus? Impressive!

Haha yes. You caught me :)

I was wondering when someone was going to point it out. I actually have only been using it since about 2009 after a brief flirtation with SVN and a horrible breakup with CVS.

Re: The future of version control

#248

Post by jsmith45 »

fn-mote wrote: post #108
bob1029 wrote: post #79

I think there are still strong advantages to the centralized locking style of collaboration. The challenge is that it seems to work best in a setting where everyone is in the same physical location while they are working. You can break a lock in 30 seconds with your voice. Locking across time zones and date lines is a nonstarter by comparison.

It seems like in a reasonable sized org you should not be merging so often that “centralized locking … across time zones” should be an issue. Are people really merging that often? What is being merged? Doc fixes?

The file locking approach is one used by centralized version control systems, and are mostly used in the everybody commits directly to trunk style of development. In those environments merging isn't much of a thing. (Of course this style also comes with other challenges, especially around code review, as it means either people are constantly commit unreviewed code, or you develop some other system to pre-review code, which can slow down the speed of checking things in.)

This approach is actually fairly desirable for assets types that cannot be easily merged, like images, sounds, videos, etc. You seldom actually want multiple people working on any one file of those at the same time, as one or the other of their work will either be wasted or have to be re-done.

Re: The future of version control

#249

Post by computably »

bigfishrunning wrote: post #147
hungryhobbit wrote: post #21

Earlier quoted context omitted.

They address this; it's not that they don't fail, in practice... the key insight is that changes should be flagged as conflicting when they touch each other, giving you informative conflict presentation on top of a system which never actually fails.

Isn't that how the current systems work though? Git inserts conflict markers in the file, and then emacs (or whatever editor) highlights them The big red block seems the same as "flagged", unless I'm misunderstanding something

With git, conflicts interrupt the merge/rebase. And if you end up in a situation with multiple rebases/merges/both, it's easy to get a "bad" state, or be forced to resolve redundant conflict(s) over and over.

In Jujutsu and Pijul, for example, conflicts are recorded by default but marked as conflict commits/changes. You can continue to make commits/changes on top. Once you resolve the conflict of A+B, no future merges or rebases would cause the same conflict again.

Re: The future of version control

#250

Post by csomar »

I am working on merge conflicts tool[1], so this area is of interest to me. But I fail to see the points of the author. In the first example he gave, git will actually give you three blobs: our, their and ancestor. The ancestor should have the missing information from his example and using code diffs[2], you can see what happened at each blob. Essentially, his blob is a single view of the 3 blobs merged together. Could be useful on the terminal, but if you are using a visual tool, a 3-way diff is always better.

> merges never fail

I am not sure what never fail means here.

> Conflicts are informative, not blocking. The merge always produces a result.

What does this even mean? You merge first and review later? And then other contributor just build on top of your main branch as you decided you want to change your selection?

If you want a smarter merge conflict tool, the one I am enthusiastic about today is Mergiraf: https://codeberg.org/mergiraf/mergiraf

1: https://codeinput.com/products/merge-conflicts 2: https://codeinput.com/products/merge-conflicts/demo

Post reply on HN