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

31–40 of 309 posts

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

#31

Post by tinco »

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 if you consider only the functionality it's meant to solve. If another "better" VCS would ever become popular I feel it would have to be a drastic change to the way of working with VCS, even more drastic than SVN to Git was. There's some cruft in Git that could probably be taken away, and that would make Git better in a theoretical sense, but in the real world that would never happen (unless we get sideswiped by another industry or platform).

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

#32

Post by mike_d »

rglullis wrote: post #19
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.

Please, Github is so much more than git hosting. If all it offered was source hosting, no one would care for it.

Github isn't all git, but all git is Github.

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

#33

Post by dreamcompiler »

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.

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.

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

#34

Post by Aachen »

zadokshi wrote: post #10

The inner workings of git are not overly complicated. The real problem is git only provides a thin layer on top of the inner workings. It’s not git that needs replacing, (it’s just saving blobs of data) it’s the user interface on top that is confusing. The problem with simplifying the user interface is that abstracting away the complexity is super difficult.

Git feels a lot like pgp to me: somehow we're not managing to make things simple enough for use by the general public, even when you only need a few buttons and input fields.

There's differences, such as that pgp is more complicated under the hood and it being a cryptographic system that needs to be foolproof whereas in git you can nuke and re-clone without data loss most of the time, let alone confidentiality/integrity loss. It just feels very similar in that only expert users properly use it and most people who could make use of it don't bother learning because the interfaces available are such a struggle (beyond basic operations anyway)

Whether it can all be solved with a simpler user interface, or whether it would require a simpler underlying system to be able to make simpler standard operations, is where I'm not sure

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

#35

Post by AeroNotix »

superb_dev wrote: post #22
dreamcompiler wrote: post #17

Besides the frontend problems with git that everybody talks about, the backend could be improved. It's now line-oriented. It would be more useful if it knew about the semantics of the language you were writing so it could show you semantic differences. That might also provide a mode for binary files which git doesn't handle very well now.

Before we can get a vcs that understand semantic diffs, we need a way to communicate semantic diffs. That way each file type can have its own “semantic differ”. Similar to how language servers help abstract away the differences for IDEs

Y'all know you can change the diff viewer git uses, right?

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

#36

Post by abenga »

pulse7 wrote: post #6

Of course there is a room for improvement... One of the biggest issues is usability/user experience: pull, fetch, checkout, commit, push, rebase - what is all this and what is the exact meaning? I need simple English terms for my work - like update and save - nothing more. Why do I need to worry about implementation details and terms? If I can not explain it to my wife, then I can not use it for binary documents whic…

If the specific words used are the problem, using aliases is a straightforward way to fix them. If you do it for someone, it will break the possibility of searching for help online though.

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

#37

Post by PhilipRoman »

Git is great for keeping track of logical history, but personally I find that it is missing tools for handling physical history. Reflog is a step in the right direction but it has a limited size and AFAIK it is not possible to share a reflog between clones. Which leaves "cp -r repo repo.backup" as the best option.

Of course, as long as you only do additive changes via commit/merge/revert, the logical history is equivalent to the physical history, but commands like rebase break this model. And despite the flaws of rebase workflows, sometimes it is the best option, like when maintaining a fork.

To my surprise Vim actually has something like this - logical history with undo/redo and physical history with g+/g-/:earlier/:later

Another thing I would like is some way to "fold" multiple small commits into one bigger one (for display purposes only) as it would let me split large diffs into minimal, self-contained commits while maintaining a reasonable git history.

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

#38

Post by VoxPelli »

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…

Locally there’s a kind of version control for branches in the “git reflog” where you can see how a branch alias has been moved

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

#39

Post by zxt_tzx »

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.

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

#40

Post by ysofunny »

PhilipRoman wrote: post #37

Git is great for keeping track of logical history, but personally I find that it is missing tools for handling physical history. Reflog is a step in the right direction but it has a limited size and AFAIK it is not possible to share a reflog between clones. Which leaves "cp -r repo repo.backup" as the best option. Of course, as long as you only do additive changes via commit/merge/revert, the logical history is equiv…

what's the difference between physical history and the logical one?

thanks in advance

Post reply on HN