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

281–290 of 309 posts

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

#281

Post by kmacleod »

darose wrote: post #264
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…

> Git has no such problem. There’s nothing it can’t do. It can't display me the branch I'm working on, starting from the commit that began the branch, until the last commit. (Or if it can, I have no idea how to do it.) This isn't a functionality issue, but rather a conceptual one. Git just fundamentally thinks of branches differently than I do. (And, maybe most humans?) To me, a branch begins ... when I branch it. To…

  git log ..
I often need the count of commits, usually for build IDs,

  git rev-list --count  ^
I usually use gitk for visualizing branch commits. CLI equivalent is

  git log --graph --oneline --all

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

#282

Post by yencabulator »

Smaug123 wrote: post #279
yencabulator wrote: post #271

Earlier quoted context omitted.

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

The git object system is based on objects having types. There was a time when the "tag" object type did not exist. The only difference between then and now is the installed base.

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

#283

Post by yencabulator »

baazaa wrote: post #278
yencabulator wrote: post #276

Earlier quoted context omitted.

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

You can absolutely build a system that fetches a git remote whenever it updates, you just need some sort of a notification/subscription system to know when to trigger it.

You can absolutely build a system that pushes (some of?) your branches on every commit.

For me personally, that'd be annoying; every time I talk to the git server, I want to insist on a Yubikey touch.

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

#284

Post by mmis1000 »

sliq wrote: post #202

Yes! In my bubble, we just need "code snapshots" or versioning, but not for the whole repo, more for each function / file. It's surprisingly hard to get juniors into git, there are so many crazy situations all the time.

The fact that a git commit is literally a code snapshot...

Hey, git don't even store diffs at first place. All it store is the snapshot of all directory content. The diff git showed to you is actually generated on the fly. You can even just clone a single commit and get the content out of it if you are doing ci and don't need the complete history.

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

#285

Post by aulin »

janalsncm wrote: post #240
dolni wrote: post #86

Earlier quoted context omitted.

There has been a lot of push to commoditize software engineering. Unfortunately that has resulted in a swarm of people who want developer salaries without the work or expertise. Git definitely has some warts but you are right. It is an industry tool for expert, professional use. Some complexity is inherent to the problem of version control. Learning how to use your tools is part of ANY trade.

I disagree. There’s always more that can be learned about anything but we live in a world with finite time and finite resources. So you can either devote time to learning git or you could spend it doing the actual work. The fact that git is used by experts and professionals is not an excuse for poor UX. The experts and professionals are almost never Git experts or professionals. I use my car every day, that doesn’t m…

I often heard this argument from people learning LaTeX in academia. It's difficult and I don't have time to study it. From people that spent years to master advanced maths, people that spent years to learn how to build and operate state of the art experimental setups. But for some reason there's never time to learn your software tools.

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

#286

Post by allarm »

slalomskiing wrote: post #262
withinboredom wrote: post #185

Earlier quoted context omitted.

This is a solved problem with git. I’ve worked on bigger projects than yours with histories that are so big you can’t clone them if you wanted to. I’ll make a note to drop what to google for tomorrow, but basically the history is fully available but git knows how to query it over the network. When you open a file, it loads it over the network. Remote build systems do your builds. Most of this was built by Microsoft t…

> Add to that the necessity for less-technical people (artists, designers, VFX, audio, etc) to use it How is that solved with Git?

Maybe they just need to follow carefully written instructions created by more technical people?

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

#287

Post by lpapez »

dolni wrote: post #256
lpapez wrote: post #100

Earlier quoted context omitted.

A tool can be both beginner friendly AND powerful for advanced users. Speaking of your analogy, the role that most software developers fullfil is not an engineer wondering about the oscilloscope, but rather the construction worker installing electrical fixtures wondering why the cable clamp has such a weird interface. Both the oscilloscope engineer in an office and the worker doing the field work would benefit from h…

> IMO the largest share of developers today are doing brick-laying work (which of course takes skill, I am not underestimating it) and would benefit a lot from having simpler tools - they don't need to know how to use an oscilloscope at all. They're doing brick-laying work until they aren't. Most problems are easy to solve and don't require very much fussing over. The expertise comes in knowing which problems are wor…

> Reducing software engineering to a low-skill trade when there is, in fact, mountains of complexity is surefire way for software to be a heap of shit. And in a lot of ways it already is.

I fully agree with this observation, but the reality is that this is where things are going.

Software quality is simply not that relevant today for the majority of software. As long as the billing works fine, the management is happy to see your website barely working - screw the quality if the money is coming in anyway.

Such software costs much less and can be built by bricklayers.

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

#288

Post by allarm »

tester756 wrote: post #105
dolni wrote: post #86

Earlier quoted context omitted.

There has been a lot of push to commoditize software engineering. Unfortunately that has resulted in a swarm of people who want developer salaries without the work or expertise. Git definitely has some warts but you are right. It is an industry tool for expert, professional use. Some complexity is inherent to the problem of version control. Learning how to use your tools is part of ANY trade.

>It is an industry tool for expert, professional use. If you were talking about things like Kubernetes, LLVM, Ghidra then I'd agree. But no git. This is not some expert tool. This tool's purpose is literally to manage your characters' history, that's it. Git could be used by any other profession that deals with letters - article writers, book writers, etc, etc.

> This tool's purpose is literally to manage your characters' history, that's it.

Yes, but you seem to heavily underestimate the complexity of the problem and the volume of the use cases that git solves.

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

#289

Post by zxt_tzx »

tansan wrote: post #51
zxt_tzx wrote: post #39

I think Git itself is probably too entrenched to be displaced by now, but I recently came across Graphite ( https://graphite.dev/ ) and, while it’s all still Git under the hood, it abstracts away many of the common pain points (stacking PRs, rebasing) and has nice integrations with GitHub and VS Code.

This is really interesting. Have you tried it before? How do you like it?

Hey, I have only just started to use it. My colleagues swear by it, which is how I've found out about it in the first place.

I think there's no magic and we'll still have to resolve merge conflicts on our own, but my sense is it does simplify repetitive operations.

Hope this helps!

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

#290

Post by Noneofya »

withinboredom wrote: post #185
dafelst wrote: post #117

Earlier quoted context omitted.

While I feel like this is generally true for most programmers and knowledge workers, Git is absolutely not suited to the workflow of several industries, including the one I work in: games. Working with an engine like Unreal Engine for a project of any reasonable size requires working with both hundreds of thousands of active files (my current project's repo's HEAD has ~400k) and hundreds of gigabytes of active files,…

This is a solved problem with git. I’ve worked on bigger projects than yours with histories that are so big you can’t clone them if you wanted to. I’ll make a note to drop what to google for tomorrow, but basically the history is fully available but git knows how to query it over the network. When you open a file, it loads it over the network. Remote build systems do your builds. Most of this was built by Microsoft t…

>Most of this was built by Microsoft to work on Windows with git.

Hacking git into something it is not does not qualify as learning to cope with git in my book.

Apparently git does not solve all problems and there is indeed value in exploring other options and building new systems that fill other niches.

Post reply on HN