Live data from Hacker News

Dolt is Git for data

dolthub.com

101–110 of 196 posts

Re: Dolt is Git for data

#101
post #76

Earlier quoted context omitted.

Git succeeded because of Linus. Sure as hell wasn't because of the UX, else Mercurial would have won, or even DARCS. 99.99999% of projects are not the Linux kernel

Mercurial would not have won. Mercurial has since added features, that are not the recommended workflow according to their docs, to have similar branching model to git but the default "as designed" workflow of hg is arguably inferior to git (yes, I know that word will get downvoted). Without git, git's style of branching would likely never have been added to hg and even though it's been added now AFAICT hg people don…

Git branching is not intuitive, because they are not branches but pointers/labels. When you talk about the master branch, you actually talk about the master pointer.

The other VCSes have an intuitive concept of branches, because they are in fact branches.

I liked Mercurial more than Git, but when BitBucked dropped Mercurial I also switched to Git.

Re: Dolt is Git for data

#102
post #76

Earlier quoted context omitted.

Git succeeded because of Linus. Sure as hell wasn't because of the UX, else Mercurial would have won, or even DARCS. 99.99999% of projects are not the Linux kernel

Mercurial would not have won. Mercurial has since added features, that are not the recommended workflow according to their docs, to have similar branching model to git but the default "as designed" workflow of hg is arguably inferior to git (yes, I know that word will get downvoted). Without git, git's style of branching would likely never have been added to hg and even though it's been added now AFAICT hg people don…

Nice to read this. I was trying to collaborate on a single project that used Mercurial, and man as a git user I could not understand the branching model.. had the hardest time. I ended up working from a local git repo, doing my work there, and then very carefully pushing the commits one at a time at the very end. If I made a mistake, I basically re-cloned the Hg repo because apparently editing history is a no-no. I found the experience very frustrating.

Sibling comment to mine:

> Git branching is not intuitive, because they are not branches but pointers/labels.

Funny, that's exactly why I DO find git branches more intuitive.

Re: Dolt is Git for data

#103
post #13

Very cool! The world needs better version control for data. How does this compare to something like Pachyderm? How does it work under the covers? What is a splice and what does it mean when it overlaps? https://github.com/liquidata-inc/dolt/blob/84d9eded517167eb2... Is it feasible to use Conflict-free Replicated Data Types (CRDT) for this?

Hi Sid, if you are curious about how it works internally, you can read some of the old docs from Noms here (Dolt uses a fork of Noms as its internal storage layer).

https://github.com/attic-labs/noms/blob/master/doc/intro.md

To answer your question, it is pretty easy to make Noms (or Dolt) into a CRDT by defining a merge function that is deterministic.

We experimented with this in Noms but the result wasn't that satisfying and we didn't take it any further:

https://github.com/attic-labs/noms/blob/master/doc/decent/ab...

Re: Dolt is Git for data

#105

A year or so I looked into "git for data" for medical research data curation. At the time I found a couple of promising solutions based on wrapping git and git annex: GIN: https://gin.g-node.org/ datalad: https://www.datalad.org/ At the time GIN looked really promising as something potentially simple enough for end users in the lab but with a lot of power behind it. (Unfortunately we never got it deployed due to orga…

Came here to say the same regarding datalad.

Re: Dolt is Git for data

#106
Dolt is not Git for data.

Git take existing files, and allow you to version them.

Git for data would take existing tables or rows, and allow you to version them.

A uniform, drop in, open source way to have an history or row, merge them, restore them, etc. that works for Postgres, Mysql or Oracle in the same way. And is compatible with migrations.

You can have an history if you use big table or couchdb, not need for Dolt if it's about using a specific product.

Re: Dolt is Git for data

#107
post #76

Earlier quoted context omitted.

Git succeeded because it was free, and then business models were able to be built up around the open-source ecosystem after a market evolved naturally. There is a need, but if you go into it trying to build a business from scratch, you're going to have a bad time.

Git succeeded because of Linus. Sure as hell wasn't because of the UX, else Mercurial would have won, or even DARCS. 99.99999% of projects are not the Linux kernel

Before git came along monotone was looking like the best DVCS.

But it had no chance to compete with Linus’ marketing power.

Re: Dolt is Git for data

#108
Non binary data can be saved as text - for example you can have an SQL database dump. You can put that text into git. What does this solution add to that simple idea?

Re: Dolt is Git for data

#109

Dolt is not Git for data. Git take existing files, and allow you to version them. Git for data would take existing tables or rows, and allow you to version them. A uniform, drop in, open source way to have an history or row, merge them, restore them, etc. that works for Postgres, Mysql or Oracle in the same way. And is compatible with migrations. You can have an history if you use big table or couchdb, not need for D…

You can nitpick any comparison like that by pointing out the different ways the metaphor breaks.

Re: Dolt is Git for data

#110
post #97
post #76

Earlier quoted context omitted.

Git succeeded because of Linus. Sure as hell wasn't because of the UX, else Mercurial would have won, or even DARCS. 99.99999% of projects are not the Linux kernel

I'd argue it succeeded (at least more recently) because of the UX that companies like Github and Gitlab gave, not particularly linus or because it was free.

Github was made because people wanted to use Git really bad, but the UX wasn't there. Git was already successful at that point.

Git succeeded because it was good. Github just made it more accessible.

Post reply on HN