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

121–130 of 309 posts

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

#121

Post by anonuser123456 »

flohofwoe wrote: post #96
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 keeps the entire history on your local machine, this becomes a problem if your project grows to several hundred GB (not untypical in game dev). Even SVN was much better for working with large repositories, you only needed a big server. Git is quite nice for "source code only projects though".

git supports shallow clones.

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

#122

Post by thfuran »

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…

>Mercurial, because hey it was written in Python, so must be good, right? right?;

Well, I can't really say that that's why, but yeah. Mercurial's pretty great.

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

#123

Post by stevenjgarner »

philipwhiuk wrote: post #93
dreamcompiler wrote: post #33

Earlier quoted context omitted.

Many companies host git besides github (gitlab and bitbucket to name two), and you can spin up one of your own in about 1 minute on your hardware or on a private cloud vps. A github server is much easier to set up than a subversion server. The reason people use github is because it's free, and because it has issue tracking and a wiki and forking which plain git knows nothing about.

> A github server is much easier to set up than a subversion server. You can't set up a GitHub server.

The intention I got from @dreamcompiler was that "A git server is much easier to set up than a subversion server.", which I feel is true.

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

#124

Post by blibble »

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.

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

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

#125

Post by Smaug123 »

armchairhacker wrote: post #65

Yes, but due to its simplicity + extensibility + widespread adoption, I wouldn’t be surprised if we’re still using Git 100+ years from now. The current trend (most popular and IMO likely to succeed) is to make tools (“layers”) which work on top of Git, like more intuitive UI/patterns ( https://github.com/jesseduffield/lazygit , https://github.com/arxanas/git-branchless ) and smart merge resolvers ( https://github.com…

The canonical example of a merge that is impossible via Git's `recursive` is a base of "AB" (where each character appears on a single line but I've omitted the newlines for brevity), branch 1 is one commit containing "AXB", and branch 2 which is a commit "GAB" followed by another commit "ABGAB". Then the recursive merge of the two branches into each other cannot tell which AB pair in branch 2 the X from branch 1 should be inserted into, because it never sees the first commit of branch 2 which tells you that the "original" AB is the one after the G. `recursive` cannot distinguish between "AXBGAB" and "ABGAXB" as possibilities. A merge algorithm which looks at every commit can know that "ABGAXB" is more faithful to the actual sequence of events, because it knows which AB pair the X was inserted into on branch 1.

(Another plausibly correct answer of course would be "AXBGAXB", but again `recursive` doesn't know enough to guess this answer.)

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

#126

Post by TheCondor »

Yes, it will be superseded. Will the new thing be “better?” I guess that depends on the metric and needs. “ls” was done but exa/eza came along and they have users.

Pondering it, most of the easy things I can think about are really workflow issues on top of git. Git doesn’t exactly enforce them all though so maybe tighter integration would be a reason to change from git if it could not be adapted. Short of that, it’s hard to imagine that a new generation of engineers simply won’t do a new thing to do a new thing; there will be a “git considered harmful” article or a “modern” replacement for git.

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

#127

Post by calamari4065 »

mike_d wrote: post #16

Subversion was really good. It wasn't perfect, but it was relatively painless. Instead everyone switched to a "distributed" version control system that is such a pain in the ass it is all now hosted by a single company.

My very first programming job used Subversion. Even as a freshly minted programmer I knew we were using it completely wrong.

My first assignment was to spend several days picking apart an extremely nasty merge conflict from two branches nearly six months diverged. That was a very stupid thing to trust me with, as a major refactor was being blessed by my idiot hands.

Management could not figure out how they wanted to maintain a master/production branch.

Our 'trunk' was the develop branch, and any time we wanted to push to production.... We deleted the master branch and made a copy of develop. Master branch had no history, you had to track it back into develop and hope you found a trailhead from there.

It was a very bad time, and we were left with a very bad product. By the time I left, the codebase was so rotten and broken that we'd abandoned all hope of fixing the deeper issues.

I really hated subversion, but mostly the company was just unbelievably mismanaged. I'm sure you can use SVN in a sane way, just not like this

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

#128

Post by Smaug123 »

aulin wrote: post #24

No, git is perfectly fine. You just need to study it to master it, just like every other tool we use in our craft.

"Fine" is not "optimal". The mere fact that something does the job does not make it the best possible thing that does the job.

The most trivial example of a thing that is wrong with Git and which no amount of getting better with the tool can possibly help is "once you generate a conflict, you cannot perform any other versioning operations until you fix the conflict or revert". In particular, for example, you cannot commit a partial resolution of a conflict: you simply have to bail out and try and put your histories in a state that is more acceptable to the merge algorithms before trying again.

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

#129

Post by jzl »

flohofwoe wrote: post #96
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 keeps the entire history on your local machine, this becomes a problem if your project grows to several hundred GB (not untypical in game dev). Even SVN was much better for working with large repositories, you only needed a big server. Git is quite nice for "source code only projects though".

Microsoft created the git virtual file system to address this so that they could move Windows to git. It has since been replaced by “Scalar”.

https://learn.microsoft.com/en-us/previous-versions/azure/de... https://github.com/microsoft/scalar

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

#130

Post by martinvonz »

johnwheeler wrote: post #114
rapnie wrote: post #9

Jujutsu version control system looks very promising in the way it brings the best of other DVCS'es together and innovates on various concepts. It has been discussed a number of times on HN before. [0] https://github.com/martinvonz/jj [1] 4 montsh ago, 261 comments https://news.ycombinator.com/item?id=36952796 [2] 2 years ago, 228 comments https://news.ycombinator.com/item?id=30398662

I tried this, and I loved it. It works very well with my workflow. Perhaps the author can explain - when you clone the repo with jj git clone It pulls down a branch that is auto generated like pull-(hash) I can’t understand how not to get that corrupted so when I do a jj log, I get very weird branches or heads or I’m not sure what. Another way to say it is that everything works great until I have to pull down the rep…

I can't tell what the problem is based on that description. Feel free to file a bug report, or start a GitHub discussion, or ask on Discord.
Post reply on HN