[besson3c]

It seems like kind of a drag for the developers of these apps (there are two that I know of, one called Versions) that now that these are out there their usefulness is fairly limited since a lot of people seem to be ditching Subversion for Git. Do these developers plan rewrites for Git?

I've been using Git for a little while now and I'm quite impressed. Git is actually pretty user friendly, much more so than Subversion, and I would say that it really doesn't require a tremendous amount of user savviness to use, especially compared to Subversion and its predecessors.

In addition to these particular apps, what do you think the future of version control will be like with Desktop apps in general? I'm wondering if we're at a point where some of these vendors might decide to standardize on Git?

Version control seems like something that many people want, can be immensely useful, but many are afraid to touch it due to its various complexities and confusing aspects. Writing a Subversion GUI must be incredibly hard. At least judging by Git's overall design, I would imagine that writing Git support would be a lot easier. Are we far off from a CoreVersion sort of framework?

So, do you think that we'll ever see a standard version control system built into mainstream apps? Do you guys have any success/horror stories or experience with Git?

[larkost]

The biggest impediment to high-quality git front-ends is probably going to be that it is GPL. This means that you can't link to the git code without being GPL yourself. So you can't really make a commercial front-end for git like you can for SVN (which is apache licensed).

In theory you could make something compatible with git that would be licensed under something more commercial-friendly than GPL, but "keeping up with the jones" would always be difficult.

There are also a number of other competitors that would have to be sorted through (ie.. Mercurial and others)

[besson3c]

Hmmm.. I hadn't thought about licensing issues, that's a very good point. What if you made Git support some sort of standalone plug-in that was open source? Would that be compatible with licensing?

[Chuckit]

Nope. The GPL requires that any code running in the same process must also be under the GPL. The only way a non-GPL program can use GPL code is by running it in a separate process. So the only practical way to make a closed-source Git client would be to have it run the normal git program in the background and just send messages to it.

[besson3c]

I think we're talking about two different cases here, probably my fault.

Case 1: run a dedicated Git client - something like Versions
Case 2: devise some sort of shim to tether Git to commercial applications

Case 1 I understand the client would have to be GPL, that's cool. Case 2 I'm more intrigued by and was what I had in mind with my last post. Perhaps some sort of lightweight plugin or applet sort that developers could link to, maybe sort of in the style of Growl? If this software itself was open source, would that be compatible with licensing?

I understand that with applications like Photoshop that deal with binary data formats you wouldn't get the full usage out of Git that you would get otherwise, but what would it take to write some sort of support for data types such as the MS Office or OpenOffice formats so that Git would be able to diff and merge and the like with these particular formats? This is another, unrelated question