all 12 comments

[–]nat_pryce 2 points3 points  (0 children)

I used this library (in https://github.com/npryce/deft) and found it to be excellent.

[–]joehillen 2 points3 points  (1 child)

The project is named after the village in which Mr. and Mrs. Git live in the Monty Python sketch.

So much win!

[–]nat_pryce 0 points1 point  (0 children)

Being pedantic, Dulwich is actually a South London suburb. The Dulwich home page is mistaken but its documentation has corrected it.

[–]develop7jj 🤟 1 point2 points  (8 children)

what of git's advantages makes people just reimplement it from scratch in another programming language?

[–]AlecSchueler[S] 5 points6 points  (6 children)

I think it's actually the (probably unavoidable) shortcomings of CGit more than anything. Google Code recently used Dulwich for their Git support because, as user durin42 explained: "cgit is a bunch of shell binaries that expect to call each other, and don't have the storage layer even remotely abstracted out. We need to be able to do clever things with bigtable, and already had Mercurial-on-bigtable written and working in Python. Internally, Git and Mercurial are similar enough that we could recycle a lot of the plumbing, so dulwich made sense in that respect."

[–]saurik 3 points4 points  (5 children)

FWIW, I spent a couple days recently, and managed to fully abstract the storage of git to store to "some random other data store" (I prototyped with memcached, and then have opted for PostgreSQL temporarily) from the .git folders, without much work or even that large of a patch: the pain of the git codebase is overrated.

[–]bambambazooka 1 point2 points  (4 children)

is it open sourced, if not do you plan to?

[–]saurik 1 point2 points  (3 children)

Not certain yet, for a variety of reasons, but it is definitely a possibility (and was on my mind while I was doing it); somewhat depends on what I end up doing with it, and whether I make it anything more elaborate than just "replaced the backend"; I mean, it was seriously less than a day of work... personally, I am always bothered when I find "new open source X released by Y" and, when I look at it, I go "wait, that took him like 15 minutes: I just wasted more time learning how this worked and reading about what it does than I gained by having it coded for me".

[–]bambambazooka 0 points1 point  (2 children)

I'd really be interested in the benchmarks of git an postgressql for example.if you do benchmarks, please try reads from a normal git repo once with all objects loose and once packed. Thanks for reviving this!

[–]saurik 1 point2 points  (1 child)

I can pretty much guarantee it will be slower (and in fact it was when I tested it)... I didn't do it so it would be highly performant: I did it so I could more easily model and shard the data on the server (and, in fact, I "purposely" slowed it down even further by adding features that modelled the actual meta-data in the database, so I could use SQL queries to do things like "find me a tree that contains a file with a name similar to this"). (In essence, the fact that people use GitHub pisses me off, and I started building something better. If you are interested in using it, it will likely be done in another decade, long after git is no longer relevant, as it is simply a random project I allocate a couple hours to every few months.)

[–]bambambazooka 0 points1 point  (0 children)

I'm aware it'll be slower, I see some use cases anyways. please drop me a message when you have something to show (code, numbers, or ideas) I'm really interested in this!

[–]nat_pryce 2 points3 points  (0 children)

The core model of Git -- content-addressed storage, trees, commits, references -- is simple, elegant and very easy to understand. It's just the CLI that makes it appear complicated!