Is it a good example? I'm not very firm with licensing. As far as I understand it git is not a library or a programming language, which means that even if you use it commercially you're not really modifying or repackaging it in your software, so there's really no duties arising out of it even if you use it on your servers. Your software is just communicating with git.
You probably have the term linking in mind to draw the conclusion that if you're merely exec'ing an external binary, this exempts you from GPL restrictions. But that term is used in the L(!)GPL to state an ok method of bundling your code along with the licensed lib. AFAIK, that GPL code is ok to bundle with proprietary software whenever GPL-ed code is invoked in a separate process, though heard frequently, has yet to stand in court, especially when said proprietary software is just a wrapper or web interface.
git is a both domain specific programming language and library of software routines that enable version control. Curious why you don't see it this way.
It's a separate program though, so you're not repackaging, modifying or redistributing.
Let's take for example TortoiseGit, should they decide to sell TortoiseGit now, they wouldn't have a problem with the GPL because they're not redistributing git. They just say, download git and our program will connect to it. Git does not become part of TortoiseGit at any point. You could replace the git client with one that has the same interface and it would still work.
Whether TortoiseGit is a derivative work of Git is ultimately a legal question. Certainly just being a separate binary doesn't automatically make it not one. "You could replace the git client with one that has the same interface and it would still work." - that's true of any library used in any program.
Unless you're building (as your company's product) a Git client based on Git, then the license of Git is irrelevant. It does not enter into the question of how you must license your product when you publish it.
Most people who have chosen to include Git in their development stack don't suffer any consequence from the fact that it is licensed as GPLv2. TortoiseGit is another matter altogether – ~in fact it must be licensed as GPLv2, because it links to libgit2. If it was changed to wrap the Git binary instead, then what you say is probably true.~ (this is false, [1] libgit2 is licensed as GPLv2 with the Linking Exception. So clients that link to it need not be licensed as GPLv2.)
But most of us Git users are not actually building Git clients.
Describing git as a DSL stretches the term quite a bit.
('DSL' can be a valuable lens to view a program though. Just like viewing things as eg file systems or databases can sometimes give you deeper insight.)
Is it a good example? I'm not very firm with licensing. As far as I understand it git is not a library or a programming language, which means that even if you use it commercially you're not really modifying or repackaging it in your software, so there's really no duties arising out of it even if you use it on your servers. Your software is just communicating with git.
Please correct me if I'm wrong.