Live data from Hacker News

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

news.ycombinator.com

231–240 of 309 posts

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

#231

Earlier quoted context omitted.

>I understand that people might want to make it easier, since the UI is complex, but that’s never going to work. If you abstract away the complexity of the UI, you will necessarily abstract away the power. I disagree, really. There is not fundamental reason why you cannot have user-friendly UI for 98% of the cases and some "advanced" for those 2%. Just like GUIs have "advanced" settings, the CLI can have well designe…

Do it then. Many have tried. All have failed. Talk is cheap.

But your talk "it's impossible, trust me" is cheaper since it's a much stronger claim

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

#232
post #196
post #68

Earlier quoted context omitted.

100% fossil. there has been a few threads.. and always someone points out edge cases that are only to be solved using git.. well i dont think so. you can actually go into the sqlite db and change stuff. i've recently started playing with its server api to direct user feedback from web to fossils ticketing system. it is just mature and feature packed and i honestly hope it will get as much recognition as sqlite someda…

> you can actually go into the sqlite db and change stuff _Nothing_ history-relevant can be changed via manipulation of the Fossil db. In terms of db records, as opposed to space, the db is about 80-90% a transient cache of data which is generated from the remaining (100% immutable) data. Any changes you make to that transient data will be lost the next time that cache is discarded and rebuilt. A longer explanation c…

thanks for the clarification! i'd still be in for a fossil t-shirt :)

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

#233
Theo describes how Graphite was built on top of git (and Github) to improve DX: https://youtu.be/I88z3zX3lMY

The main innovations seem to be:

- The concept of a "stack" which is somewhere between a commit and a branch, a group of commits.

- Better UI, especially for Github notifications.

The end result is he feels safer using advanced git features and can move faster, especially when working within a team of multiple devs.

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

#234
post #214

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…

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!

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

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

> I understand that people might want to make it easier, since the UI is complex, but that’s never going to work. If you abstract away the complexity of the UI, you will necessarily abstract away the power. There's a lot of "useless" complexity in the Git UI. The naming of the commands and the underlying concepts are quite inconsistent. The commands themselves are inconsistent. It's rare to see somebody, even git fan…

We could get aliases that get slowly incorporated into git. Like, let's say git undo instead of git reflog, or things like that. It would not be too difficult to support a couple of names to do the same thing and let people use the one they prefer.

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

#236
Git is perfect, it just needs a good UI.

The best UI in my opinion is sourcetree, which is not available on linux.

I worked with sourcetree years ago (switched to linux last years and used smartgit client), I don't know the current state, but old versions are available to download, and don't require an atlassian account.

Some improvements I could suggest are the ability to ammend a commit which is not the last (and not pushed of course).

Currently if you want to ammend the third last commit for example, you have to soft reset last commit, push it to stash, reset the new last commit again and push it to stash, ammend the changes, then pop the previous 2 stashes and commit them one by one. This could be easily automated.

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

#237

Earlier quoted context omitted.

Do it then. Many have tried. All have failed. Talk is cheap.

I would say that Mercurial has a simpler UX than Git without being less powerful. I think Jujutsu (see other posts here), which I started, also has simpler UX and is more powerful than Git in many ways. Have you looked at either of those?

[dead]

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

#238

Earlier quoted context omitted.

> I understand that people might want to make it easier, since the UI is complex, but that’s never going to work. If you abstract away the complexity of the UI, you will necessarily abstract away the power. There's a lot of "useless" complexity in the Git UI. The naming of the commands and the underlying concepts are quite inconsistent. The commands themselves are inconsistent. It's rare to see somebody, even git fan…

We could get aliases that get slowly incorporated into git. Like, let's say git undo instead of git reflog, or things like that. It would not be too difficult to support a couple of names to do the same thing and let people use the one they prefer.

We are slowly getting those. For example there's now git restore (and git switch) to fix the god-awful overloaded checkout.

When you get your repo into a state that needs reflog, it's probably not amenable to very straightforward commands. A bigger problem is that it's a bit "too easy" to get into that kind of state.

The original git interface wasn't really intended for "general use" and there was supposed to be the friendlier "porcelain" on top of the lower level "plumbing". But people started to use the plumbing directly and the porcelain never came to be.

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

#239
post #189

Earlier quoted context omitted.

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

How does diffing and conflict resolution work?

[Not the person you're replying to]

Vscode has a built-in (and quite good) 3-way merge editor, and an excellent editable diff view. GitLens also makes it easy to diff any two refs within vscode.

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

#240
post #86
post #63

Earlier quoted context omitted.

Imagine an electronic engineer complaining about an oscilloscope being hard to use because he cannot explain what all those knobs do to his wife. We are professionals, our tools should be powerful for the advanced user, not beginner friendly.

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 make me a mechanic. Having to understand the inner workings of a tool is an indication of poor design, not a gatekeep we should seek to maintain.

Post reply on HN