Uses of git | Hacker News Reader

Uses of git

devsundar.github.com

190 pointssundar22in72 comments

Distributed version control is such a wonderful thing. And, I love how github has become a pseudo-wiki - letting individuals change information, knowledge and not just code. Naturally, HTML/HTTP is graph-like, but unfortunately it has converged over time into a few homogeneous master branches, owned and controlled by a few. I hope that techniques like DVCS with its branching, forking, and merging of information, can create better Wikipedias.

Have you seen Ward Cunningham's "federated wiki"?

http://wardcunningham.github.com/

Shameless alpha-testers-wanted plug:

I'm launching a website authoring collaboration tool based around Git. Let me know if you're a git fanatic who needs to build fairly simple sites from time to time, and maybe you can try it out and give me some feedback!

Figured this wasn't completely off-topic, as I'm building Yet-Another-Use-For-Git :-)

matt.beale@madhatted.com

Please don't spam the discussion.

This sounds awesome, thanks for mentioning it here. Mail sent.

Does the website use Jekyll?

Jekyll is part of what is going on, yes. But not the whole ball game by any measure!

There's also git-annex

http://git-annex.branchable.com/

Came here to mention that. Having a simple way of managing where the various copies of my files are stored is great.

That looks very interesting. I also really like how the front page shows the use-cases plainly

Another use case for git-annex (and hence git) would be host intrusion detection a-la aide, or tripwire. You'd have to add metadata tracking to make it worthwhile though.

The sentence about Torvalds might be a bit of a stretch. The approach (distributed version control) wasn't new when he created git.

Also, what is with that changing of selection color? :)

Its true that Linus did not invent distributed version control (he did not invent OS either), but git did change the world of version control systems similar to his other creation Linux.

Thanks for observation, i did not notice the selection color was pink :)

HTML5 Boilerplate uses the same selection color, so its feasible that that was used as a starting point.

I'm surprised no one has mentioned it before, not that it's revolutionary or amazing, but just so damn helpful:

Turn your /etc/ into a git repository. It'll save you hours on end of maintenance and debugging in the long run, especially when you update packages and find that your configurations have been overwritten or lost.

You should check out etckeeper, a package that does exactly that. Additionally it will hook into apt-get and similar system tools and automate Some of the revisioning

Ubuntu's page about it:

https://help.ubuntu.com/10.04/serverguide/C/etckeeper.html

Example of using etckeeper with Git on Ubuntu 10.04 LTS:

http://evilrouters.net/2011/02/18/using-etckeeper-with-git-o...

> Github and Bitbucket provide a wiki backed by git. Colloboration tools such as wikis can be run by using git.

And Gitit: http://gitit.net/

Thanks for this suggestion. Post updated. +1

On the "git as a backup tool", the author missed a tool which looks quite interesting, called Bup (https://github.com/apenwarr/bup) which is based on git's toolchain. It is still immature but worth looking at.

Thanks, Your suggestion is updated in the post.

IkiWiki (Perl-based) is another wiki backed by git (or svn, or bzr, or other VCSes), and has also other nice features like static website and blog generation.

[1]: http://ikiwiki.info/

Thanks for the link. Updated the post with your suggestion! Hope its useful for others as well.

The blog states that git can be used as a database with version control. Does anyone know of a more optimised (document-oriented) database with version control?

If not, is there an interest for one?

Could you elaborate on what you mean by "document oriented db with version control"? Couch stores revision identifiers with every document ID, though old versions are subject to deletion whenever DB compaction occurs...

Essentially, objects have the ability to be rolled back, forward etc. Support for messages attached to commits and transactional commits would be nice!

An extensible user collection would also be nice, so app users are database users and vice versa.

Veracity has a database feature which might be what you are envisioning. (Disclosure: I am one of the developers of Veracity). But I would not describe it as document-oriented. It versions a collection of records with fields in the same way that regular version control manages a collection of directories and files, with support for history and changesets and push and pull.

CouchDB? http://couchdb.apache.org/docs/intro.html

As pointed out below, versions can be garbaged by an efficient Database administrator.

I'm more interested in the "distributed" part of the story. Version control can be fitted into any database with a bit of hacking, but a distributed ACID database where you can commit to any node and merge with any other node sounds like a really interesting concept.

Especially when combined with the fact that it is extremely difficult to forge git history without getting noticed, people could use something like git as a reliable, scalable, and censorship-resistant platform for data sharing and storage.

I agree, but alternatively, we could study git and the lessons learnt there and design a distributable ACID database with version controlled data, extensible user collections and the performance of a more traditional database.

Couchdb keeps old versions of documents. And it is document oriented. So there's that.

We've dismissed CouchDB a couple of times...

No we have not. No need to be an ass.

I'm not a donkey.

We have dismissed it as the versions are deleted during compaction and aren't replicated to other nodes. Hence, dismissed.

How well does Git handle being used for syncing arbitrary files? I'd been led to believe that storing large binary blobs in it was a Bad Thing (tm).

It's not ideal. It will end up storing two copies of the data files, one in the .git folder as a blob and one for the regular file in the checkout.

There are projects (http://git-annex.branchable.com/ and https://github.com/schacon/git-media) to try and get around this issue but then you are not really using git to manage the files directly anymore.

excuse my ignorance.. but it is interesting to me that we see blog posts about how to find different uses for git. what makes git so great that we (or people writing such articles) try to retrofit it into tools that already have more mature alternatives dedicated solely to doing that one thing really well. it's some form of marketing i don't fully understand.

I see your point, and its not a marketing imho.

In some cases i agree that there are mature alternatives, but what if you dont want or cannot use them. For e.g. Dropbox is a great file storage/sync service. But you may not be able to use it inside an enterprise and store office/confidential documents.

I think its essential to know and understand various ways in which a tool can be used. So that you can apply it to solve/simplify a problem. Its not a marketing.

Isn't this what 'hacking' is (at least partially) about?

Despite the existence of 'solutions', there are lots of interesting things people can do with git and it's probably fun to explore them.

edit: I'm not sure why you consider it 'marketing' either.

I agree with the comment. Its hacking and not marketing!!

yep, i understand your point, and i do see the hacking angle. and i also see a bit of zealotism. I would be very curious to learn what benefits could be gained from hacking git to do something like a wiki (other than being able to say that you're using git for wiki). And i'm not cynical here, genuinely curious..

Well, you gain a bunch of features for free, like distributed storage, signed edits, etc. Also, I already know how to use Git, which saves me time over having to learn a whole new set of commands to use some other wiki software.

And frankly, is it really different from using someone else's library or module?

Yeah, even already knowing git isn't necessary. If you didn't learn git, you could learn it, and then you have the skills to use it for all sorts of stuff.

No specialized wiki software can be a DVCS or backup system.

The benefit i see by using git-backed wiki is that your data is not locked into any database/site. In the end they are plain text files and no dependency on database (e.g. myql), and no dependency on git-hosting site. If you dont like github, you can host your wiki else were.

doesn't that make your data less accessible/queryable?

Yes, in the end making a choice is about making a trade-off. If we need easy to query data storage then RDBMS are better.

It's simply zealotism.

The right tool for the job is always the right tool for the job.

Git is not the right tool for the job for most of the cases described.

Its true that there is excitement behind writing the post.

But imho, right is a subjective word. What is right in one environment is not right in another. The intention of the post is to be aware of the possible uses of git. Its not to say that its best for all purpose/cases.

If you understand gits internal model, it's a content-addressable data store. This happens to lend itself well to version control, but the fact that it's used for version control is somewhat incidental. It would be good if there were some way of identifying the underlying data-structures as separate from the version control system.

You can call it libgit [0]

[0] http://libgit2.github.com/

We are (ab)using git in some fun ways. Our designers use branches we setup with git flow to develop and manage assets. We deploy from develop and master branches to dev and production servers. We also use the github api to allow the dynamic loading of the assets from the head of any one of the branches for internal testing.

I've been pleasantly surprised how well the designers have taken to the workflow, and its great to take advantage of the flexibility of git especially when we don't have the time to roll our own backend to cover all those bases.

I do the same thing for testing branches and continuous deployment on EC2! +1.

I've come across a project before that used GitHub's gist API as a document store for client side apps. Can't for the life of me find it again, Don't suppose anyone else has come across this use and can remember the url (or has it bookmarked)

I asked the community this question a few months back - small discussion here

http://news.ycombinator.com/item?id=2732149

There's also Blogofile, static blog generator for Python lovers.

Thanks for the info. I love python.

Hyde is another great one, I use it for my personal site.

Fantastic post on the beauty of git. The Using git for for deployment article seems like a great micro-intro to git. Nice one!

I use Gists as user-data files for EC2 deployments. Works amazingly well.

Interesting, could you please elaborate on this use of git. It will be helpful. Thanks.

Sure. I'm actually working on a bootstrap project which uses Gists and Node.js to spin up a scaling infrastructure: https://github.com/franklovecchio/yc-bootstrap. Instead of using CloudFormation, which I loathe, or Puppet/Chef (which have a learning curve and infrastructure for latter), I use standard bash libraries (see yc-bootstrap/gists/) and "extend" them to spin up instances -- see the README under "Gisting": (https://github.com/franklovecchio/yc-bootstrap/blob/master/R...). That example is what the user-data file would be.

Thanks! +1

Allowed uses of git?

Maybe someone can shed some light on that aspect, and the webpage should too.

Every time when I see "GNU GPL" I just turn around and think it's not worth the trouble.

I'm not seeing the term "allowed" on the page. Maybe it was edited since you posted. I'm thinking that if it was used, it was probably a result of English being a second-language or something similar.

I don't understand how the GNU GPL license would impact your usage of git. Do you intend to include git with your application?

I think the intent of this article is to show you the different ways you can implement git to solve a variety of problems. The GNU GPL license is largely irrelevant to end-users of software.

Intention of the post is to show various ways in which we can use git and they are allowed uses too. For e.g. MySQL uses GNU GPL too, you can use it in your poject and use it for any purpose.

git is such a beautifully elegant concept and execution... it's so simple that i still often find myself grappling with exactly what the heck a particular command does and when it should be used.

i personally always get a small giddy thrill when i see such a wide spectrum of applications from a simple underlying concept... just like these. and each application alone is cool! DB, wiki, dropbox-clone... very, very cool stuff when considering the implications of integration on /that/ level.

but apparently this isn't a universal sentiment, given some of the comments on this thread (that i am genuinely surprised at, given what i would think is the typical "curious/hacker" mentality of the crowd here).

I think you have a fundamental misunderstanding of the implications of GPLed software.

If you incorporate GPLed software into your own software - that is, copy the source code - then your work is considered a derived work and is also under the GPL.

Software that is LGPLed can be linked to without making your application under the GPL itself. This includes things like glibc. (The "L" in "LGPL" used to stand for "Library" but now it means "Lesser.")

Finally, if you use GPL software to produce your own works, there is no effect. So using git to manage your own source has no impact. Same with using gcc to compile your source.

Good explanation!

I thought that the grand-parent comment referred to sentences such as this from the article:

"Git can be used as a database for your application."

If you intend to distribute your application, even though you're not copying the git source code directly, nor linking your application directly against a git library, the GPL is rather ambiguous.

"Pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program." -- http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#Me...

Minor correction: the LGPL relaxes the reciprocity requirement for code that uses the LGPL code; linking isn't the only example, imports in dynamic languages is another.

The GPL doesn't have a reciprocity requirement; it's a pay-it-forward system.

Reply on news.ycombinator.com