Git remotes behind firewall and using a network drive

[chendaniely]

@iglpdc and I figured out how to teach git at the federal reserve by using the user's mapped drive as a git remote

thanks @gvwilson for forwarding @wking's response that started my google-fu. I successfully (it worked!) taught it to the class, and was wondering should I write this up for other instructors?

If not for the students who attended so that they have a reference we can send them.

tldr; git clone --bare my_repo my_repo.git now every time there is a local push, you have to pull from the server

[wking]

On Thu, Sep 25, 2014 at 11:17:57AM -0700, Daniel Chen wrote:

tldr; git clone --bare my_repo my_repo.git now every time there is
a local push, you have to pull from the server

I've been a fan of this self-hosted approach for a while, although I
suggested using the Git daemon instead of a network share 1. I
think the question is whether or not we're trying to introduce folks
to GitHub at the same time we introduce them to Git. Personally, I
like opting into closed-source software more than starting folks out
there. But maybe folks like the web UI, and aren't satisfied by
Gitorious, GitLab, etc.? Die-hard GitHub fans could probably teach
our whole version-control lesson using GitHub's web UI, and never
touch a command line at all.

[chendaniely]

@wking I had them use the network share because everyone here has one and I wanted to simulate some environment so they can use it right away.

What I could do is write up a PR for what I did and we can tweak it so it's more universal.

The only thing I did not like about the way I did it was that in the remote server there is a my_projects/directory and a my_projects.git/ directory. the pushes all went to my_projects.git, and they had to cd to the my_projects directory, setup a remote, and remember to always pull from my_projects.git/

edit: @wking daemons on the server only work if you have the proper permissions, right?

[wking]

On Thu, Sep 25, 2014 at 11:57:01AM -0700, Daniel Chen wrote:

I had them use the network share because everyone here has one and I
wanted to simulate some environment so they can use it right away.

Everybody has a Git daemon and an IP address too ;). However, they
might also have a firewall that they don't understand, which would
make my approach more complicated. Given a high enough density of
Linux boxes (or an “instructor hosts the daemon” model) I think it
would work as well as the network-share approach. It may even be more
portable. For example, I don't expose my NFS exports publically, and
I don't have a cloud data account with an external provider.

What I could do is write up a PR for what I did and we can tweak it
so it's more universal.

I'd support that, but you should wait and see if others are interested
before diving in on the patches ;).

The only thing I did not like about the way I did it was that in the
remote server there is a my_projects/directory and a
my_projects.git/ directory. the pushes all went to
my_projects.git, and they had to cd to the my_projects
directory, setup a remote, and remember to always pull from
my_projects.git/

What was in the remote my_projects/? My bare Git repositories are
just a single my-project.git/. There's no getting around declaring a
remote, pushing, and pulling though. That's how interacting with a
public repository works (wherever it is hosted ;).

[chendaniely]

What was in the remote my_projects/?

I did a mkdir my_projects and then inside the directory touch file{1..3}.txt to simulate the fact that they already have a project in a network drive and they want to begin to git track it now

[wking]

On Thu, Sep 25, 2014 at 12:36:20PM -0700, Daniel Chen wrote:

What was in the remote my_projects/?

I did a mkdir my_projects and then inside the directory touch file{1..3}.txt to simulate the fact that they already have a
project in a network drive and they want to begin to git track it
now

Ah, so they have both their working, non-bare repository and their
public, bare repository on their network share. I suppose that's ok.
Personally, I'd just keep the bare repository on the share, and then
have local working repositories anywhere I sit down. That way you can
polish your commit messages while you're on the train ;). More
importantly in this context, I think it helps emphasize the
distinction between “this is my private repository, where I work” and
“this is my (semi-)public repository, which I push too when sharing”.

[chendaniely]

my thinking was: "their boss (and/or other lab mates) might not know git, so when they open that bare repo up they'll be absolutely lost (maybe angry)" :p

[wking]

On Thu, Sep 25, 2014 at 12:43:42PM -0700, Daniel Chen wrote:

my thinking was: "their boss (and/or other lab mates) might not know
git, so when they open that bare repo up they'll be absolutely lost
(maybe angry)" :p

My approach to that is to use Git's gitweb 1. Then they can browse
the repository, download archives, …. Without a stable IP to serve
that from it's more difficult. I'd probably use a free hosting
service (Gitorious, GitLab, Bitbucket, GitHub, …).

If the code was too secret for trusting to an external company, I'd
just call:

$ git archive …

when I wrapped up for the day. For example:
—
$ git archive -o /path/to/share/my-project-$(date --iso-8601=date).zip master

When folks got tired of unpacking the zips/tarballs, I'd suggest they
install Git and start using pull ;). But it's also possible that I'm
a bit more anti-cloud, pro-self-hosting than your average student ;).

[iglpdc]

Hi,

I have to say that it worked pretty well today. People were confused at first by the bare repo, but at last it may pay off in the sense that it gives a feeling on what a 'regular' repo really is.

Also, it saves you from one of the points that people often make: "I don't want to put my thesis/code in GitHub and have everybody seeing it". You can say: make a "server" out of a USB stick and carry it around.

I'd suggest to put this either as an extra short lesson, or at least in the instructor's bag of tricks.

Best,

Ivan

El 25/09/2014, a las 16:07, "W. Trevor King" [email protected] escribió:

On Thu, Sep 25, 2014 at 12:43:42PM -0700, Daniel Chen wrote:

my thinking was: "their boss (and/or other lab mates) might not know
git, so when they open that bare repo up they'll be absolutely lost
(maybe angry)" :p

My approach to that is to use Git's gitweb 1. Then they can browse
the repository, download archives, …. Without a stable IP to serve
that from it's more difficult. I'd probably use a free hosting
service (Gitorious, GitLab, Bitbucket, GitHub, …).

If the code was too secret for trusting to an external company, I'd
just call:

$ git archive …

when I wrapped up for the day. For example:

$ git archive -o /path/to/share/my-project-$(date --iso-8601=date).zip master

When folks got tired of unpacking the zips/tarballs, I'd suggest they
install Git and start using pull ;). But it's also possible that I'm
a bit more anti-cloud, pro-self-hosting than your average student ;).

—
Reply to this email directly or view it on GitHub.

[chendaniely]

@gvwilson @jhamrick do you still want me to write this up and send a PR and tag it for after #759 ?

[gvwilson]

Definitely, but after the big reorg.
Thanks,
Greg

[gvwilson]

Replaced by swcarpentry/git-novice#224