Live data from Hacker News

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

news.ycombinator.com

81–90 of 309 posts

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

#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 fast, at the cost of the cli user experience.

That said, git is big enough that multiple companies have come along and "solved" the git UI problem. None of these aftermarket UI layers are perfect, but there are enough of them and they are different enough that you can probably find one that is good enough for you, along whatever axis you personally dislike the git UI (examples include [0], [1], [2], which tackle very different user workflow problems).

[0] https://git-fork.com/

[1] https://graphite.dev/

[2] https://news.ycombinator.com/item?id=7565885

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

#82
post #63
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…

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.

Agreed. Imagine a pilot complaining that the controls are not simple enough.

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

#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 GitHub desktop app (https://desktop.github.com/)did a great job of visually showing git flows and functions, but for a non-tech/programmming person, the tool would be daunting.

Curiosity what your suggested tech stack would be - sans Terminal…

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

#85
post #8

Earlier quoted context omitted.

To be honest, I can’t even imagine what you imagine “git save” and “git update” would even do in an alternate universe.

This is funny because in PR oriented development I started treating commits in the same way as "save" in IDE, it's just backup of current state with irrelevant commit message. Everything is described at the end of the work in PR's description and squash merged.

Giant PRs that are squashed into one commit are an anti-pattern. Every commit should contain exactly one logical change AND a descriptive commit message.

Unfortunately a good chunk of the industry doesn't have the discipline to do this.

If you have ever worked in a project where there was discipline around committing, you know there is lots of value in doing so (rebasing becomes easier, you unlock the power of bisect, log is actually useful).

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

#86
post #63
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…

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.

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

#87
post #66
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

Surprised this is done in Rust. I could never imagine not doing the v1 of something like this in Python or similar, to be able to change things quickly. Maybe the design was very clear on the person's mind.

I feel the opposite way.

Even though Python is the language I’ve used most, I wouldn’t want to use it for something with a lot of uncertainty and that will suffer many changes. Type systems make it so much easier to change things early on without breaking everything. I’d probably pick F# or similar.

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

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

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.

> ..because it saves snapshots rather than changes..

I might be misremembering the technical details, but isn't that only the case in a git repo with zero pack files?

Will grant that the lack of metadata on renames can be issue when a file is heavily refactored alongside it's relocation.

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

#89
post #60

Earlier quoted context omitted.

Can you clarify what you mean by "version control of branches"? Branches in Git are just labels of objects. Are you talking about having a history of which objects a branch has previously labelled, like the reflog?

Yeah, I feel the reflog is more of a tool to do introspection on a git repository than that is a tool for collaboration. It's just something I've felt was missing from Git. If you're looking at the main branch of a repository, what was the previous version of that branch? The way we work around that missing feature is by tagging commits so we don't forget what revision a release was made at for example. A sequence of…

Merge commits mostly solve this problem if you use them.

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

#90
The only thing I wish git handled better out of the box, with without any flags/setup, is large/binary assets.

LFS is ok but it still feels like a kludge to me.

The cli does not bother me, there are many tools that offer alternatives/overlays/UIs. Not saying it is perfect or even good, but it's good enough - for me at least.

Post reply on HN