The git-shell is a restricted shell maintained by the git developers and is
meant to be used as the upstream peer in a git remote session over a ssh tunnel.
The basic idea behind this shell is to restrict the allowed commands in a ssh
session to the ones required by git which are as follows:
git-receive-pack
Receives repository updates from the client.
git-upload-pack
Pushes repository updates to the client.
git-upload-archive
Pushes a repository archive to the client.
Besides those built-in commands, an administrator can also provide it’s own
commands via shell scripts or other executable files. As those are typically
completely custom, this post will concentrate on the built-in ones.
The current trend of social coding finally arrived at ERNW! From now on, you
will find our public released tools and scripts commonly
on https://github.com/ernw. Therefore I would like to
share some thoughts/guidelines which you have to keep in mind if you want to be
a social coder:
Github and other repository hosts are great if you want to share opensource
tools with the community, as they will find a common platform with defined
workflows to extend/fix the work to get better software for everyone. What some
should note is that (especially in terms of decentralized version control
systems (DVCSs) like git, bazaar or mercurial) public really means public. Back
in earlier days, if you shared your code with others you probably created a
source code package of a defined version of your code. They will get the files
you published, nothing more (and nothing less). Beginning with websites like
sourceforge, a broader range of public VCSs came up (mostly driven by CVS or
SVN). At this time, others were able to view your commit history (if you granted
access to them) and all your mistakes you’ve done before your published code
state (for example accidentally committed sensitive data). Those mistakes can
still happen today. The difference with the DVCS used nowadays is that most of
the time you have lesser control of your commit history (in the same way if
someone had copied your history commit by commit in SVN, but then you may had
noticed it because of the high network traffic). With DVCS, everyone gets a full
copy (clone) of your repository even on a simple “checkout” (as called in SVN).
This means he/she is able to search your history locally and has all the time
he/she needs to do it. Even if you delete your repository (or modify the
history), the original state is shared over all who have cloned it beforehand
(thats one reason why DMCA takedowns are not that powerful/useful against git
repositories). Most of the public hosting platforms even included a search over
all repositories (which is really useful if you want to find some tool or try to
find the reason why a local tool doesn’t work).