Question about Source Control

Chris Angelico rosuav at
Tue Mar 18 08:09:51 CET 2014

On Tue, Mar 18, 2014 at 5:42 PM, Frank Millman <frank at> wrote:
> Excuse my ignorance, but how does it actually work?

Ignorance not only excused, but welcomed. :) However, caveat: I know
how git is set up, but not hg. Someone else can fill in the details;
for now, I'll explain git and hope that hg is broadly similar. I
expect it will be.

> Do you set up some kind of client/server relationship, and if so, how do the
> clients (machines B and C) access the software on machine A?

For read-only access, git can run its own protocol, but for read/write
it's most common to run it over SSH. Every pull or push is implemented
by git calling on ssh to run either 'git send-pack' or 'git
receive-pack' on the other end. (It's common to set it up with a
restricted shell that can *only* run those commands, although I also
find this usage convenient for cloning between two computers that I
control, rather than fetching from upstream. It's immensely faster
downloading something over a virtualized gigabit ethernet link than
over the internet!)

So it goes by the rules of SSH. There's a user account on the target
computer, which owns all the files in the repository. That user
account might have a password on it (which you type in every time you
pull/push), or you might use public/private keys to authenticate, or
whatever else you've set up. That part isn't git's responsibility. On
Linux systems, it's usually pretty easy to set up openssh and a
dedicated account; on other servers, I assume it can't be hard to get
something going.

> I know that Mercurial can run its own web server, and clients can access it
> through http. It that what you are suggesting? That would be quite a change
> for me, as on my linux box I do all my work from the command line on a
> console.

You'd still do everything from the command line. You type "git clone
blahblah" or "hg clone blahblah", and everything happens under the
covers. The only way you'd know the difference is if the "blahblah"
part identifies the protocol (which it usually will, but that's
somewhat beside the point).

> These are the kind of stumbling blocks that prevented me from succeeding in
> my previous attempt. I have a vague recollection that I set it up on machine
> A, but then hit a problem because machines B and C both accessed the same
> directory, but with different names - on Windows, a mapped drive and on
> linux a mounted nfs directory. I had to provide a 'path' name to set up
> Mercurial in the first place, but I could not find one that suited both
> clients.
> I feel that I have just not grasped the basics yet, so any assistance that
> puts me on the right path is appreciated.

Yeah, a distributed repository solves that. You could have three
entirely different path names on the three computers, and nothing will
care. (You have to be careful to use relative paths everywhere
internally, of course, but you probably do that already.) It's pretty
efficient once you get used to it; I recommend poking around on the
internet for a git tutorial or an hg tutorial, depending on which you
go with. It's not too hard, but there are a lot of commands to keep
track of. Here's a helpful quick reference to the differences between
the two:

As a git-familiar and hg-novice, I keep that handy every time I'm
working with hg on anything more complicated than "keep up with the


More information about the Python-list mailing list