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.
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 :-)
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.
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 :)
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
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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'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)
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.
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.
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.
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).
