151–160 of 196 posts
Inside are a bunch of binary files. It would be interesting to know more about the on-disk layout of the stored tables.
I was not able to find any documentation. Does someone know more about this? Pointers would be appreciated.
An example use case that "git for data" seems to break: storing data for medical research where the participants are allowed to withdraw from the study after the fact. Then their data must be deleted retroactively, not just in the head node. I don't know of a good methodology for dealing with this at all as it breaks backups, for example. The problem extends beyond medical research due to privacy laws like the GDPR.…
I think data (as in raw, collected / measured / surveyed data) doesn't really change, but you get more of it. Some data may occasionally supersede old data. Maybe the schema of the data changes, so your first set of data is in one form, and subsequent data might have more information, or recorded in a different way.
One really important feature of time series data is the preservation of what the dataset looked like at each point in time. Financial data providers will make a mistake (off by order of magnitude, missed a stock split, etc) and then go back and correct it. This means you end up training models entirely on corrected data, but trade based on uncorrected data.
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
This caused a firestorm, some defended him, others defended Bitkeeper, and a lot of people said why the hell is Linus using proprietary software to manage an Open Source project?!?!! Linus waded in and said he'd think about it, I think was on a thursday or friday, and by the next week he had working python prototype of git. [2] The rest is history. Bitkeeper faded into irrelevance and git became the lingua franca for open source projects. Arguably its biggest strength was not revision control, but being designed in manner that many collaborators could seamlessly commit changes for merging. Obviously architected to fulfill the time consuming requirements of Linus Torvalds, it has stood a test of time. I'm writing this from memory, so if it disagrees with Wikipedia take it with a grain of salt.
[1]: https://en.wikipedia.org/wiki/BitKeeper#Original_license_con... [2]: https://en.wikipedia.org/wiki/Git#History
I can't tell from the font - is it DOLT - delta Oscar lima tango - or DOIT delta Oscar India tango?
Earlier quoted context omitted.
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.
AFAIK (from the rumour mill and not from any kind of reliable source) the `git branch` command was only added as a cargocult from all the SVN users flocking to git and asking "So how do I branch?!". Previous to this, everything was tags and checkouts. Again, no verifiable source, just water cooler talk with other devs.
https://marc.info/?l=git&m=111377572329534
I don't know about 'git branch', but it looks like 'git merge' wasn't a thing
edit: from searching a bit, it appears that it had branches on June of the launch year, dunno if it had those on release.
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
DARCS would not have seen significant further growth, due to the merge-of-doom problem.
Earlier quoted context omitted.
That's Git Hub for data. It's a service, and they still haven't launched anything yet. This is Git for data. It's a program, and it appears to be an open-source one you can download and use today.
There is actually an old git for data project too: https://github.com/datproject/dat It's ~5 years old and I really wanted it to be huge. Hoping this new project is a success. Especially since I notice I went to high school with one of the founders of Dolt (Hey Tim!)
I'm not sure why you bring it up now. They don't call it "git for data" anywhere that I see, and it's missing 2 of the 3 core features that I think a "git for data" would need to have.
Earlier quoted context omitted.
That's Git Hub for data. It's a service, and they still haven't launched anything yet. This is Git for data. It's a program, and it appears to be an open-source one you can download and use today.
The OP points to a site called DoltHub.com, so it’s not like they don’t have ambitions to commercialize as another “GitHub for data”.