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

121–130 of 407 posts

Re: The future of version control

#121

Post by clktmr »

IgorPartola wrote: post #97
kungito wrote: post #85

Earlier quoted context omitted.

After 15 years i still cant remember which is which. I get annoyed every time. Maybe I should invest 15 minutes finally to remember properly

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.

The thing is, you'll typically switch to master to merge your own branch. This makes your own branch 'theirs', which is where the confusion comes from.

Re: The future of version control

#123

Post by IshKebab »

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…

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 that I'm sold!

Re: The future of version control

#124

Post by awesome_dude »

kungito wrote: post #85
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…

After 15 years i still cant remember which is which. I get annoyed every time. Maybe I should invest 15 minutes finally to remember properly

This is one of my pain points, and one time I googled and got the real answer (which is why it's such a pain point).

That answer is "It depends on the context"

> The reason the "ours" and "theirs" notions get swapped around during rebase is that rebase works by doing a series of cherry-picks, into an anonymous branch (detached HEAD mode). The target branch is the anonymous branch, and the merge-from branch is your original (pre-rebase) branch: so "--ours" means the anonymous one rebase is building while "--theirs" means "our branch being rebased".[0]

[0] https://stackoverflow.com/questions/25576415/what-is-the-pre...

Re: The future of version control

#126

Post by yammosk »

gojomo wrote: post #105
skydhash wrote: post #48

Earlier quoted context omitted.

> 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 s…

If you're relying on a serialized 'source of truth', against which everyone must independently ensure their changes sanely apply in isolation, the. you've already resigned yourself to a single-threaded process that's slower than what improved merges aim to enable. Sure, that works – like having one (rare, expensive) savant engineer apply & review everything in a linear canonical order. But that's not as competitive &…

And yet after all these year of git supporting no source of truth we still fall back on it. As long as you have an authoritative version and authoritative release then you have one source of truth. Linus imagined everyone contributing with no central authority and yet we look to GitHub and Gitlab to centralize our code. Git is already decentralized and generally we find it impractical.

Re: The future of version control

#127

Post by IgorPartola »

clktmr wrote: post #121
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.

The thing is, you'll typically switch to master to merge your own branch. This makes your own branch 'theirs', which is where the confusion comes from.

Not me. I typically merge main onto a feature branch where all the conflicts are resolved in a sane way. Then I checkout main and merge the feature branch into it with no conflicts.

As a bonus I can then also merge the feature branch into main as a squash commit, ditching the history of a feature branch for one large commit that implements the feature. There is no point in having half implemented and/or buggy commits from the feature branch clogging up my main history. Nobody should ever need to revert main to that state and if I really really need to look at that particular code commit I can still find it in the feature branch history.

Re: The future of version control

#128

Post by barrkel »

hackrmn wrote: post #118
barrkel wrote: post #96

I don't really get the upside of focus on CRDTs. The semantic problem with conflicts exists either way. You get a consistent outcome and a slightly better description of the conflict, but in a way that possibly interleaves changes, which I don't think is an improvement at all. I am completely rebase-pilled. I believe merge commits should be avoided at all costs, every commit should be a fast forward commit, and a uni…

When you say "unit of work", unit of _which_ work are you referring to? The problem with rebasing is that it takes one set of snapshots and replays them on top of another set, so you end up with two "equivalent" units of work. In fact they're _the same_ indeed -- the tree objects are shared, except that if by "work" you mean changes, Git is going to tell you two different histories, obviously. This is in contrast wit…

By "unit of work", I mean the atomic delta which can, on its own, become part of the deployable state of the software. The thing which has a Change-Id in Gerrit.

The delta is the important thing. Git is deficient in this respect; it doesn't model a delta. Git hashes identify the tip of a tree.

When you rebase, you ought to be rebasing the change, the unit of work, a thing with an identity separate and independent of where it is based from.

And this is something that the jujutsu / Gerrit model fixes.

Re: The future of version control

#130

Post by aggregator-ios »

What CRDT's solve is conflicts at the system level. Not at the semantic level. 2 or more engineers setting a var to a different value cannot be handled by a CRDT.

Engineer A intended value = 1

Engineer B intended value = 2

CRDT picks 2

The outcome could be semantically wrong. It doesn't reflect the intent.

I think the primary issue with git and every other version control is the terrible names for everything. pull, push, merge, fast forward, stash, squash, rebase, theirs, ours, origin, upstream and that's just a subset. And the GUI's. They're all very confusing even to engineers who have been doing this for a decade. On top of this, conflict resolution is confusing because you don't have any prior warnings.

It would be incredibly useful if before you were about to edit a file, the version control system would warn you that someone else has made changes to it already or are actively working on it. In large teams, this sort of automation would reduce conflicts, as long as humans agree to not touch the same file. This would also reduce the amount of quality regressions that result from bad conflict resolutions.

Shameless self plug: I am trying to solve both issues with a simpler UI around git that automates some of this and it's free. https://www.satishmaha.com/BetterGit

Post reply on HN