How is git used as other than the project's version control?

I'm interested in finding out how people use git "on the side", when it is not the project's actual version control system.

I'm aware of the vague idea of using it to "go remote".

I'm sure I'll use it for non-programming topics just as an undo system.

But what about using it as a tool, wielded separately from applying those tools to a git repository infrastructure? For example, use it to separate out hunks and untangle mixed work. You could do this even if your directory has nothing to do with git normally.

--John (please forgive the footer; it's not my idea nor my choice)

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

2009/4/27 John Dlugosz <JDlugosz@tradestation.com>:

What is it you're really asking here? I use "git diff" all the time outside of $GIT_DIR for instance -- invaluable, and was designed deliberately that way.

-- Thomas Adam

When putting together a presentation on git, I created a simple-looking slide claiming that "developers will use git anyway" as a general-purpose tool. I find lots of web chatter about using it as a lighter-weight front-end to an Enterprise VCS, or as part of a technique for working away from your desk in such a system. But it got me thinking about how it might be more like a text editor in the sense if being more generally useful than just that specific thing it's "for". But I don't have any concrete examples, just a vague notion.

== beware, monster footer ahead==

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
  If you received this in error, please contact the sender and delete the material from any computer.

2009/4/28 John Dlugosz <JDlugosz@tradestation.com>:

Well, still you skirt around the main issue,  I use git in numerous scenarios:

*) As a front end to a CVS and/or SVN repository. *) To manage files in my $HOME directory.

In the case of the first point, I have people using CVS/SVN directly without them ever knowing I used git to commit my changes therein,

Is this what you're asking?   It's certainly possible and not too difficult.

-- Thomas Adam

On Mon, Apr 27, 2009 at 06:55:38PM -0400, John Dlugosz wrote:

Thomas already mentioned using "git diff" separate from a git repository; I find that "git diff --color-words" is much nicer than "wdiff", which does something similar (though I rarely use it outside of a repo only because I put _everything_ into git :) ).

One of the nice things about git (and other distributed VCS's) is that creating a repo is very lightweight. If I am going to write a patch for some other software, the first thing I'll do after untarring it is "git init; git add .; git commit -m import". So it kind of blurs the concept of "what is the project's actual version control system" as you wrote above. If you consider the project to be my patch, it _is_ the VCS. Even though upstream may not be using it.

And of course, if I am going to do multiple patches, then I may convert and track upstream's history via git.

If you are looking for exotic uses of git, you may be interested in Dscho's "Using Git For What It Is Not Intended" contest:

  http://search.gmane.org/?query=UGFWIINI

-Peff

Jeff King wrote:

This...

... although I usually *always* do this, even if it's only one patch.

On Mon, 27 Apr 2009 15:55:38 -0700, John Dlugosz <JDlugosz@tradestation.com> wrote:

I don't know if this suits your need or not, but I use it to track configuration changes and history in servers and equipment.

Octavio.

2009/4/27 John Dlugosz <JDlugosz@tradestation.com>:

We have historically used a very simple pessimistic locking strategy with our legacy platform source. Individual files or groups of files are checked out to developers' home directories and they override what's in the live area when that dev compiles and tests for themselves.

I basically inserted git under this mechanism, thus allowing the optional use of merge and integrate (lockless development), topic-branches, tags etc. Git also functions as our tripwire solution to ensure changes to that master shared repo have all been made traceably.

Git effectively is the VCS now, as what was there before was only barely acceptable when it came to accessing old versions etc, but if you don't want to interact with git, you don't have to even know it's there. Until it saves your arse.

Mike

"John Dlugosz" <JDlugosz@TradeStation.com> writes:

2008-01-31: Git is the next Unix http://www.advogato.org/person/apenwarr/diary/371.html