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

291–300 of 407 posts

Re: The future of version control

#291

Post by qsera »

adastra22 wrote: post #284
qsera wrote: post #274

I think this was something that was waiting for something like LLMs to happen to be solved. Why aren't AI companies touting "zero-shot"ing huge merge conflicts being resolved by LLMs..

Have you tried this? It would be a nightmare. The LLM wold "solve" the merge conflict by eliminating the code.

But that should make the builds or some tests to fail no? I think we can consider it as a first approximation and proceed to a manual review. It should be a lot easier than manually resolving the difficult merge..

Re: The future of version control

#292

Post by masklinn »

theknarf wrote: post #164

You can't use CRDTs for version control, having conflicts is the whole point of version control. Sometimes two developers will make changes that fundamentally tries to change the code in two different ways, a merge conflict then leaves it up to the developer who is merging/rebasing to make a choice about the semantics of the program they want to keep. A CRDT would just produce garbage code, its fundamentally the wron…

Both jj and pijul save (~commit) conflicts to be resolved later, rather than require immediate resolution.

And jj was built around rebase being a routine operation, often transparent (cherrypicking being a form of rebasing).

Re: The future of version control

#293

Post by ozim »

lmm wrote: post #231
KPGv2 wrote: post #211

Earlier quoted context omitted.

I'll be honest, as a fairly skilled and experienced programmer who isn't a git expert, I know what HEAD means, but when I'm rebasing I really have no idea. It all seems to work out in the end because my collaborative work is simple and usually 2–3 people only, so I'm never rebasing against a ton of commits I lack context for (because 90% of them are my commits since I'm usually dealing with PRs to my open source proj…

I avoid this problem by not rebasing.

Hey not every rebase has conflicts. I definitely rebase when there are no conflicts, then merge.

When there are conflicts I merge „theirs” into my branch to resolve those so I keep mental model for this side and don’t have to switch. Then rebase then open PR.

Re: The future of version control

#294

Post by ozim »

jimbobimbo wrote: post #268
lmm wrote: post #231

Earlier quoted context omitted.

I avoid this problem by not rebasing.

Seriously! I have too many years of software development experience, but I use Visual Studio UX to handle pretty much all git operations. And always merge. I have better things to do in my life than "internalizing" anything that doesn't matter in the grand scheme of things.

I don’t like that approach, because people who work like that commit all kind of crap to repo or cry that GIT ate their homework…

Then we have line ending conflicts, file format conflict UTF8-BOM mixes with just UTF8 it makes more work for everyone like crappy PRs. Because of people for who those are things that „don’t matter in grand scheme of things”.

Re: The future of version control

#295

Post by lmm »

ozim wrote: post #293
lmm wrote: post #231

Earlier quoted context omitted.

I avoid this problem by not rebasing.

Hey not every rebase has conflicts. I definitely rebase when there are no conflicts, then merge. When there are conflicts I merge „theirs” into my branch to resolve those so I keep mental model for this side and don’t have to switch. Then rebase then open PR.

You could do all that. Or you could just merge every time. I know which I find easier.

Re: The future of version control

#296

Post by hyttioaoa »

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.

I often find myself using the gitlens in vscode, to do something similar. I'd compare the working tree to the common base. Then I have the left pane with what's already in the base, the right pane is editable with the result in it.

It's nice to have all the LSP features available too while editing.

Re: The future of version control

#297

Post by forrestthewoods »

I hate Git. I think it is mediocre at absolute best.

But nothing in this article is in my top 10. So this doesn’t really do anything for me.

All I really want is support for terabytes scale repo history with super fast, efficient, sparse virtual clones. And ideally a global cache for binary blobs with copy-on-write semantics. Which is another way to say I want support for large binary files, and no GitLFS is not sufficient.

Re: The future of version control

#298

Post by IshKebab »

pfg_ wrote: post #235
IshKebab wrote: post #123

Earlier quoted context omitted.

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…

I tried p4merge a while ago and it didn't do it ubfortunately, still stuck copying the base and ours to seperate files and diffing them.

So the way you can do it in VSCode is to open the conflict in their smart merge editor... Often it is actually smart enough to highlight the relevant change but if not each of the left/right editors has a button in its toolbar to diff it against the base.

Not the easiest to access but better than copying/pasting (which is what I also used to do).

Re: The future of version control

#299

Post by tome »

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

It doesn't matter which is which. The resolution will be the same regardless.
Post reply on HN