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

211–220 of 309 posts

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

#211

Post by mihaic »

I first user Git about 10 years ago, going from Accurev and Perforce. Those VCSs were a bit heavy to configure, but their UI allowed a lot of complex and easy workflows to happen at the same time.

Git won by being free and since a lot of people think using the terminal is somehow better, but we could have done a lot better in terms of UX and power. Command line programs force you to have a lot of context in your mind, and if git would have been designed with a UI it would have been probably better for everyone.

I still hope for better tools, but they'll probably be based on Git, just with better default flows.

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

#212

Post by [deleted] »

aaomidi wrote: post #191
vtbassmatt wrote: post #187

Earlier quoted context omitted.

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

Oh awesome, thank you for asking for clarification! What really slows me down, and honestly just kinda annoys me is that when I’ve cloned some upstream repository onto my machine and made a bug fix, why do I need to then fork the repository once more and push the commit to my fork first and then go through the theatrics of making a PR? GitHub the server could, for example, fake my branch on the origin/upstream. It do…

[deleted]

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

#214

Post by est31 »

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…

Microsoft had a bunch of solutions to handle their massive Windows repo: VFS for Git (GVFS), Scalar, and now it has a bunch of MS specific patches on top of the official git client, but apparently that one is also not required any more as partial clone is now supported on azure as well (which is another such implementation from Microsoft employees that made it to both GitHub and upstream git).

So yeah, solved problem thanks to Microsoft. Solved multiple times in fact, and because it's Microsoft, only not all had Linux installers: https://github.com/microsoft/scalar/issues/323#issuecomment-...

https://github.blog/2020-01-17-bring-your-monorepo-down-to-s...

https://devblogs.microsoft.com/devops/introducing-scalar/

https://github.com/microsoft/git

https://devblogs.microsoft.com/devops/git-partial-clone-now-...

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

#215

Post by creatonez »

shard_ wrote: post #207
rendall wrote: post #119

Earlier quoted context omitted.

> doesn't capture some metadata changes like renames If you rename the file using git and that is the only change in your file, then it works: git mv oldfile newfile Commit that change and the rename is in your history.

`git mv` is just shorthand for `git rm` and `git add`. All Git knows is that there was a file called `oldfile` and there's now a file called `newfile`, and whether or not they have similar contents or filenames. It's only when you run `git status` or `git diff` or whatever that it actually tries to guess if anything was renamed. So what you're seeing isn't the rename being recorded in history but just that guess bein…

The parent comment's suggestion is to commit each of these moves individually, which should guarantee that the detection algorithm will get it right. Will definitely pollute your history, though.

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

#216

Post by wyoung2 »

DemocracyFTW2 wrote: post #72

> Or is it a solved problem and Git is the endgame of VCS I've read so many comments to the effect that "X is a solved problem" when it clearly wasn't that I've come to conclude that the phrase means the opposite of its surface value... I'm pretty sure that Git is not the end-of-line as far as VCSs go. Whether I will ever change my VCS, again, ever, that is an entirely different question. I've been through so many of…

> github.com…I don't want an 'impedance mismatch' between my system and their system

So give your contributors developer accounts on your Fossil instance, which is super-cheap to set up, being a single binary with nearly zero external dependencies. (Those being OpenSSL and zlib, which are table stakes these days.) My containerized build is a single static binary that compresses to ~3.5 MB, total, all-in.

If you're concerned over the lost promise of easy PRs from randos on the Internet, I question your premise. My experience is that below a certain project popularity level, there is less than one total full-time developer on the project, even counting all possible external committers. Below this threshold, why optimize for external contributors? If someone has a sufficiently valuable patch, they can deal with getting a Fossil repo login or sending a patch.

I've been the maintainer of a piece of software for coming on two decades that's in all popular package repos and have _never_ gotten a worthwhile PR for it via GitHub. I spend more time using their code commenting features explaining why this, this, and this make the change unacceptable, after which the PR submitter goes away rather than fix their patch. It's a total waste of time.

I did once upon a time get high-quality external contributions, but that was back when the project was hosted by Subversion, and it didn't matter that posting patches required more work than firing off a GH PR. People who have sufficient value to commit to a project will put up with a certain level of ceremony to get their code into the upstream project.

(To be fair, I expect the reason for the lack of quality external contributions is that the project is in some sense "done" now, needing only the occasional fix to track platform changes.)

If you are lucky enough to have an audience of outsiders who will provide quality contributions, Fossil does have a superior option for patches than unified diffs. See its "patch" and "bundle" commands. This lets your outsiders send a full branch of commits with comments, file renames/deletions, etc.

…kind of like a PR. :)

If you absolutely require integration with Git-based tooling, Fossil makes it easy to mirror your repo to GitHub, which you can treat as read-only.

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

#217

Post by Dylan16807 »

rendall wrote: post #119
bryanlarsen wrote: post #80

Earlier quoted context omitted.

The git model has fundamental limitations because it saves snapshots rather than changes, and doesn't capture some metadata changes like renames. A tool like Darcs or one of its spiritual descendants will have fewer merge conflicts than git. Totally agree on your main point though. The benefits of switching are far lower than the costs.

> doesn't capture some metadata changes like renames If you rename the file using git and that is the only change in your file, then it works: git mv oldfile newfile Commit that change and the rename is in your history.

> If you rename the file using git

Does nothing. Git won't remember you did it.

> and that is the only change in your file

This always works, but it means you need to choose between flaky rename detection and weird extra rename-only commits that probably don't compile.

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

#218

Post by dasil003 »

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…

I think it's definitely possible to create a better CLI than git, however I think the majority of what unhappy users of git are imagining when they ask for a better UI would oversimplify things and end up removing a lot of valuable capabilities. These capabilities may not be suitable for a non-technical audience, but I believe should be table stakes for professional software developers as they are very sharp tools for managing the software development lifecycle that transcend specific languages or domains one may be working in.

To take your example of moving commits between branches, the git rebase parameters and --onto flag are definitely confusing, but each of them is clear and necessary when understood. The CLI could be refactored to be clearer, but the hard part is understanding what each one means, which you would need to do anyway even with a better CLI. Obviously one can work around these knowledge gaps, but once you understand them they are useful for an entire career and the warts tend to fade in importance relative to the value of a tool with the insane power-to-weight and rock solid architectural tradeoffs of git.

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

#219

Post by jacobegold »

tinco wrote: post #31

In my opinion the feature Git has always been missing is version control of branches. Of course the immediate consequence would be that you'd be able to roll back changes to branches but there'd be some more fundamental consequences as well. I'm pretty sure some of the problems with GUI's/wrappers around Git break down because there's no tracking of branches/tags. Besides that it's pretty much endgame in my opinion i…

Phabricator and Gerrit both do a really good job of this. To me Git works fine as a pure "version control" system, but the process of collaborating on a branch before it gets merged into a shared branch seems to be beyond the scope of version control -- something that a higher layer tool is ideal for.

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

#220

Post by Affric »

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…

Great comment.

Git really needs a good git tutor game.

Like vim tutor or any one of the n*x/shell games.

Post reply on HN