Live data from Hacker News

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

news.ycombinator.com

151–160 of 309 posts

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

#151
We've been working on a data version control system called "oxen" optimized for large unstructured datasets that we are seeing more and more with the advent of many of the generative AI techniques.

Many of these datasets have many many images, videos, audio files, text as well as structured tabular datasets that git or git-lfs just falls flat on.

Would love anyone to kick the tires on it and let us know what you think:

https://github.com/Oxen-AI/oxen-release

The commands are mirrored after git so it is easy to learn, but optimized under the hood for larger datasets.

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

#152
post #32

Earlier quoted context omitted.

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

False. I'm working on two large distributed projects now in git. Neither has anything to do with github.

I think the meaning of the sentence you're replying to is that GitHub's features are a superset of Git's features which seems true?

"Github isn't all git [some features of GitHub are not in Git], but all git is Github [but all features of Git are in GitHub]."

Maybe my interpretation is incorrect?

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

#153

Earlier quoted context omitted.

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

>Do it then. Many have tried. All have failed. Talk is cheap. I'm, just like many other people using GitHub Desktop (or Git Kraken or Git Extension, but I dont like this one) when I'm working in GUI environment, that's proof that it is possible. The problem with creating 3rd party tool that's CLI wrapper is that you cannot rely on it being installed on the system. That's why such solutions usually fail - because you…

I'll share here my positive opinion of GitExtensions (on Windows). It has really helped me use and better understand Git, while also helping me define and share workflows with my colleagues..

Other GUIs, like the ones embedded in VisualStudio, VSCode or Rider, try to sell skipping some cognitive steps for some operations as simplifying or speeding up dev flow. I find they are just offering extra (beyond what git itself offers) ways of shooting yourself in the foot.

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

#154
Yes, I think that we can do better than plain text as the source of truth, and thus git would probably need to change.

There's work around a bunch of languages that are not based on text, some have their own editor or a tool to manage a canonical representation in text for you that would make them friendlier to git.

  - https://github.com/yairchu/awesome-structure-editors/blob/main/README.md

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

#155
I’ve worked with git since 2016. I guess I must not be a power user because beyond using like six got commands I’ve never had any issues or felt like man my workflow is interrupted.

What features do you think need to be improved? From a purely UX pov I think git is probably the best software I’ve used. It just works.

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

#156
post #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 fas…

I generally don't hear too many complaints about GIT in the Windows/.NET development world, probably because there are good UI front ends and there's not as much 'tough guy' cred from sticking to the CLI. Visual Studio does a decent job of abstracting the GIT nuances, but I personally use GIT Extensions, which looks and feels much better on Windows than the other cross platform UIs. I drop to the CLI occasionally, es…

I too am a fervent GitExtensions apostle.

I really wish the 4.* release supported a dark theme, it's the only thing keeping me on the 3.* release, and I dread the day I'll have to switch for whatever reason...

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

#157
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'm not particularly productive in python. The code gets shat out faster but it's a comparatively weak language for capital-P Programming — lack of types means repeating and checking yourself a lot.

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

#159

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.

there was such a thing for c#, called semantic-merge by Codice Software, a Spanish company that after being bought by Unity, killed it...

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

#160

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.

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

Is there a difference?
Post reply on HN