Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Can we do better than Git for version control?

news.ycombinator.com

Post reply on HN
Print view View original

271–280 of 309 posts

Re: Ask HN: Can we do better than Git for version control?

#271

Post by yencabulator »

Smaug123 wrote: post #269
yencabulator wrote: post #255

Earlier quoted context omitted.

Maybe you want more local clones (git clone -l -s) or to use worktrees, so you can leave a merge conflict pending in one of them? Git doesn't have a way to "store a partially resolved conflict" in a way that would remember that it hasn't been resolved. If you really want that, maybe you want to just commit the conflict markers and come back later; rebase the commits together once you're all the way done.

> Git doesn't have a way to "store a partially resolved conflict" in a way that would remember that it hasn't been resolved. Exactly my point: this is a fundamental limitation of Git for which there is no good workaround. It's not inherent to the domain, but is a limitation of Git. Pijul (for example) considers conflicted states simply to be normal.

It's less of a fundamental limitation and more of a thing that hasn't been programmed yet. Feel free to do that.

Re: Ask HN: Can we do better than Git for version control?

#272

Post by Aperocky »

cflewis wrote: post #161
Apreche wrote: post #77

A lot of people these days have just been thrown into the fire with Git as the first and only VCS they’ve ever seen. I’m not that old, but I’m old enough to have used RCS, CVS, SVN, then finally Git. I started using Git super early, before GitHub existed. You may not believe me, but Git was the answer to all my prayers. All those previous systems had fundamental architectural flaws that made them a complete nightmare…

This post is a terrible failure of imagination that would make one stop language development as C because it was so much better than Assembly. If you have no problems with Git, then I’m happy for you. I certainly have problems with Git, eg its inability to handle large repositories meaningfully (enjoy a Chromium checkout!), the arcane CLI commands, the shut-your-eyes-and-hope of moving commits between branches and ot…

> arcane CLI commands

Are the syntax of the commands the issue or are all CLI commands arcane to you? What would you propose to be the command syntax if you were designing it?

Re: Ask HN: Can we do better than Git for version control?

#274

Post by argulane »

dolni wrote: post #85
retpoline__ wrote: post #14

Earlier quoted context omitted.

This is funny because in PR oriented development I started treating commits in the same way as "save" in IDE, it's just backup of current state with irrelevant commit message. Everything is described at the end of the work in PR's description and squash merged.

Giant PRs that are squashed into one commit are an anti-pattern. Every commit should contain exactly one logical change AND a descriptive commit message. Unfortunately a good chunk of the industry doesn't have the discipline to do this. If you have ever worked in a project where there was discipline around committing, you know there is lots of value in doing so (rebasing becomes easier, you unlock the power of bisect…

This!

Also doing PR code review is soo much nicer if each commit is logically self contained with a nice commit message.

Re: Ask HN: Can we do better than Git for version control?

#275

Post by baazaa »

yencabulator wrote: post #249
baazaa wrote: post #221

Earlier quoted context omitted.

Totally agree that people spend way too much time complaining about git's solutions but there's not nearly enough criticism of the fact it's solving the wrong problem 99% of the time. I want to share 5k LOC with a colleague. Anyone who thinks that requires a decentralised solution in 2023 is unwell. I recently wasted a few hours because I forgot to fetch before running some code. Sure the UI could be better (if you'r…

What you fail to understand is that, outside of all talk about decentralization, keeping local state is a huge performance optimization. Tagging a large CVS tree used to take several minutes, because it would talk to the remote server separately about every file. History browsing & bisect are very pleasant in Git because the local computer already has all the information, and just needs to present it to you.

You can still cache things locally, it's just shouldn't be something the user has to be aware of. What I'm typing now isn't immediately being communicated to the central server every keystroke, there still is local state, but it's still a client-server architecture.

The repos I work on are often smaller than the average webpage, I'm really not buying the idea that in the age of HD streaming bandwidth-concerns are an issue here.

Incidentally none of the teams I've worked on ever even use any git features like bisect. The cult of git means everyone has to use git, even though for most people that just means many hours wasted googling with absolutely nothing to show for it (as in git is strictly inferior than just sharing files across a networked drive for many teams' use-cases).

Re: Ask HN: Can we do better than Git for version control?

#276

Post by yencabulator »

baazaa wrote: post #275
yencabulator wrote: post #249

Earlier quoted context omitted.

What you fail to understand is that, outside of all talk about decentralization, keeping local state is a huge performance optimization. Tagging a large CVS tree used to take several minutes, because it would talk to the remote server separately about every file. History browsing & bisect are very pleasant in Git because the local computer already has all the information, and just needs to present it to you.

You can still cache things locally, it's just shouldn't be something the user has to be aware of. What I'm typing now isn't immediately being communicated to the central server every keystroke, there still is local state, but it's still a client-server architecture. The repos I work on are often smaller than the average webpage, I'm really not buying the idea that in the age of HD streaming bandwidth-concerns are an…

Caching is trickier than decentralization because it's hard to know when the cache is valid. Fetch/push make that explicit, and not git's concern.

Meanwhile, others work in airplanes and in the woods.

Not using git bisect is your loss. I'm very happy it exists, and wouldn't trade git for just files on network drives.

Re: Ask HN: Can we do better than Git for version control?

#277

Post by protomolecule »

yencabulator wrote: post #249
baazaa wrote: post #221

Earlier quoted context omitted.

Totally agree that people spend way too much time complaining about git's solutions but there's not nearly enough criticism of the fact it's solving the wrong problem 99% of the time. I want to share 5k LOC with a colleague. Anyone who thinks that requires a decentralised solution in 2023 is unwell. I recently wasted a few hours because I forgot to fetch before running some code. Sure the UI could be better (if you'r…

What you fail to understand is that, outside of all talk about decentralization, keeping local state is a huge performance optimization. Tagging a large CVS tree used to take several minutes, because it would talk to the remote server separately about every file. History browsing & bisect are very pleasant in Git because the local computer already has all the information, and just needs to present it to you.

"History browsing & bisect are very pleasant in Git because the local computer already has all the information, and just needs to present it to you."

Probably the only thing that makes me not miss SVN too much.

Re: Ask HN: Can we do better than Git for version control?

#278

Post by baazaa »

yencabulator wrote: post #276
baazaa wrote: post #275

Earlier quoted context omitted.

You can still cache things locally, it's just shouldn't be something the user has to be aware of. What I'm typing now isn't immediately being communicated to the central server every keystroke, there still is local state, but it's still a client-server architecture. The repos I work on are often smaller than the average webpage, I'm really not buying the idea that in the age of HD streaming bandwidth-concerns are an…

Caching is trickier than decentralization because it's hard to know when the cache is valid. Fetch/push make that explicit, and not git's concern. Meanwhile, others work in airplanes and in the woods. Not using git bisect is your loss. I'm very happy it exists, and wouldn't trade git for just files on network drives.

Yes and pushing 'when do i update to/from the server' onto the user is exactly what I'm complaining about. No other software I use does this. Even software originally built to do things locally allows you to seamlessly update to/from a server nowadays (e.g. working on a cloud document in Word say). And any software built from the ground up to do this tends to have a great user experience (e.g. Figma).

Re: Ask HN: Can we do better than Git for version control?

#279

Post by Smaug123 »

yencabulator wrote: post #271
Smaug123 wrote: post #269

Earlier quoted context omitted.

> Git doesn't have a way to "store a partially resolved conflict" in a way that would remember that it hasn't been resolved. Exactly my point: this is a fundamental limitation of Git for which there is no good workaround. It's not inherent to the domain, but is a limitation of Git. Pijul (for example) considers conflicted states simply to be normal.

It's less of a fundamental limitation and more of a thing that hasn't been programmed yet. Feel free to do that.

I do, thank you! (But it will never be the case that conflicts are modelled in Git, unless one uses notes or something to build a more expressive database on top of it, whereupon I think it's not really reasonable to call the resulting system "Git".)

Re: Ask HN: Can we do better than Git for version control?

#280

Post by pdimitar »

gavinhoward wrote: post #201

Disclamer: I'm working on it. But yes, I think we can. Almost everything can be better: * Merges/rebase/branch management. * Project management. * Diff. * Large files. * User management. * Partial checkouts. * ACID semantics. * Binary file management. * User experience, including making it accessible to non-technical folks. * A bunch of others.

Semantic diffs would be a very long overdue, and a very welcome, change.
Post reply on HN