Live data from Hacker News

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

news.ycombinator.com

181–190 of 309 posts

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

#181
post #83

What do you recommend for non-programmers, who would still benefit from version control system. Examples: - Book author using markdown / static site generator to publish a book. Uses visual editors like Typora. - Product designers for open-source hardware. Various design files, SVG etc. I’ve experimented with a “GUI only” git flow - just to see what is possible, so I could introduce the concept to others. I found Git…

Github? You can edit and commit online. You probably don’t need to ever branch or merge

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

#183
post #144

Earlier quoted context omitted.

Does Git LFS help with this problem?

Overall LFS feels a very hacky tacked on solution with warts. Git LFS is horrible if you mistakenly add some file(s) to LFS. Restoring to LFS-less state is supposed to be easy but it is always very painful. There should be a way to tell repo - I do not want any LFS at all. In practice this is painful, and it is easier to start a new repo.... Also for some reason Github/Microsoft decided to "monetize" LFS. The freebie…

GitHub charges for LFS and has since they initially introduced it, way before Microsoft was involved. Also, the pricing model is changing and will include a minimum of 10GiB for free (250GiB for Team/Enterprise customers). It’s cost-recovery and abuse-prevention, though, not some nefarious scheme. And funny you mention AWS S3... what costs might GitHub be recovering? ;)

Microsoft’s homegrown LFS implementation (in Azure DevOps) does not and has never charged for LFS. It’s nice to have friends with a cloud blob storage service!

Source: I was the product manager for Azure Repos’s LFS server and am currently the product manager for all things Git at GitHub.

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

#184

Yes we can. The shortcomings of git are that it doesn't handle binary files well, and you can't clone a slice of a repo. the system after git will handle both of those. mono repo or not is not a question with aftergit because you can clone just a subdir and work there, without the overhead of cloning the whole thing, but also without the weight of keeping up with commits happening outside of your directory.

Like this? https://github.blog/2020-12-21-get-up-to-speed-with-partial-...

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

#185
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…

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 to work on Windows with git.

We moved from SVN in the late 2010’s, and holy crap man, did it change our workflows. No longer were we passing around patch files in a team for code reviews, but actually reviewing code somewhat like on GitHub. It was magical.

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

#186
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…

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

That’s why you need a binary repository like Artifactory and not store your large files in Git. But you can still track them in Git with the large files in a binary repository like Artifactory.

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

#187
post #98

Yes. IMHO the next VCS model should follow a centralized-first, decentralized optional model. Which would be a flip of the decentralized-first model of git. I also think GitHub is in a unique space to really innovate on git and it’s a shame they’re not. For example, I shouldn’t need to make a fork to make a PR. That’s absurd and the GitHub server should be able to apply ACLs based on the push identity. There’s a coup…

I think there are some serious ergonomic issues with forks as they’re presently implemented. However, I’m curious what you intend from:

> the GitHub server should be able to apply ACLs based on the push identity

That’s essentially exactly what a GitHub fork _is_ – an ACL’d set of refs you’re allowed to control, separate from upstream’s set of refs. I guess – what would you have us do differently?

Disclosure, I work for GitHub and am the product manager for Git stuff.

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

#188
I remember a post on HN about how YAML was a terrible serialization format. A stricter subset of YAML (eg - StrictYaml) wouldve solved every single problem mentioned there.

Similarly, the solution to git is a subset of git (strict git).

Gits problem is that it is too powerful and assumes that it's users are all git experts. You should be able to run git in 'easy-mode'. Add, commit, checkout new branch, revert, squash merge. That's all 90% of people need.

Then the intermediate folks can run it in mode 2, adding the ability to rebase, reset heads, cherry pick, revert, stash etc. This covers the next 9%.

The last 1% can use it in mode 3 for the rest.

Once you take away the fear of what you could break, git becomes far less intimidating.

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

#189
post #81

Along what axis do you want the VCS to be "better" than git? For example, git's cli user interface is monstrous (yes, I know, you personally have 800 cli commands memorized and get them all right every time, that doesn't make it "good"). From the outset, the maintainers of git basically decided "it's too much work to make all the cli flags behave and interact consistently" so they didn't. This allowed git to grow fas…

I generally don't hear too many complaints about GIT in the Windows/.NET development world, probably because there are good UI front ends and there's not as much 'tough guy' cred from sticking to the CLI. Visual Studio does a decent job of abstracting the GIT nuances, but I personally use GIT Extensions, which looks and feels much better on Windows than the other cross platform UIs. I drop to the CLI occasionally, es…

Vs code + git graph + git lens is all you need for a happy git experience.

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

#190
post #160

Earlier quoted context omitted.

the rename won't be in your history because the tree and commit objects don't support renames the tooling infers a rename based on the lack of a content change

Is there a difference?

Absolutely. In a move-and-edit situation, git will sometimes infer a rename and sometimes not, based on your local version of git, your settings, and the details of the edit. If inference fails, you may have a harder time resolving merge conflicts, performing cherry-picks, etc.
Post reply on HN