These are just notes so I can find them again next time, I know I'm missing a few concepts still, but I need to keep track of what has so far worked for me.

1. Set up a git repository and daemon

   Git and its super-localized repositories are all very well, but hardly useful for sharing, so I need an offshore git repo where my work really lives when I'm between machines. So I set up my own git repository. Following a fer online instructions, I got my rackhost machine to do this for me.
   So now I can do things like

   git clone git://git@features.coders.co.nz/features.git

   to fetch a copy of my latest Drupal 'features' experiments.
   I will not detail that set-up here, as it's in docs elsewhere. Suffice to say I eventually got it done.

2. A setting that helped early on was a global preference that tells git to assume I'm using just one default branch most of the time, unless I choose otherwise.

   git config --global push.default matching
   

   now lets get started...

3. Set up a new project, use git, and share it

   Here's the day-to-day stuff.
   I've written a small module. I think it's worth carrying on with, so get it into public git-space.
   Todays module is called 'new_zealand' because it's all about New Zealand placenames.

   
   export project_name=new_zealand
   cd $project_name
   git init
   git add .
   git commit -m "First check in of $project_name project"
   
   [master (root-commit) 9f0e2a9] First check in of new_zealand project
    8 files changed, 2562 insertions(+), 0 deletions(-)
    create mode 100644 NZ_regions_with_geolocation.csv
    create mode 100644 NZ_suburbs_with_geolocation-a.csv
    create mode 100644 NZ_suburbs_with_geolocation.csv
    create mode 100644 new_zealand.features.inc
    create mode 100644 new_zealand.features.taxonomy.inc
    create mode 100644 new_zealand.feeds_importer_default.inc
    create mode 100644 new_zealand.info
    create mode 100644 new_zealand.module
   

   Local git is happening, but there is no great joy in that.

4. Put it somewhere else.

   git remote add origin git@features.coders.co.nz:$project_name.git
   

   Note this will not complain or even check if the remote server is OK with this.
   the git@ is being used because there is a username just called 'git' that I can use on that server. I can probably use my own login name too, but this was easier to remember.

   About now you would

   git push
   

   However that gives us a complaint:

   ERROR:gitosis.serve.main:Repository read access denied
   fatal: The remote end hung up unexpectedly
   

   Because although I can communicate with the remote server, it won't let me make up a project on the fly. (Damn, in CVS or Subversion I just had to add a directory and I could extend instantly)
   So, um, I need to make up that remote project space.

   I followed the gitosis instructions, which shows how to administer the git server using config files that are themselves under git source control. So I'll do that. I've already done the tricky bit and set up the keys and things for that.

5. Set up space for and access to the project in the repository.

    pushd ~/gitosis-admin/
   

   - where ~/gitosis-admin/ is the local copy of the admin files I need to update.

   
   vi gitosis.conf
   
   [gitosis]
   
   [group gitosis-admin]
   writable = gitosis-admin
   members = dan@monster
   
   [group coders]
   members = dan@monster aegir git
   writable = features new_zealand
   

   There I added new_zealand as a new section that members of the 'coders' group can write to.

   This change was made locally, and then I use git itself to send the gitosis-admin file back up to the git-daemon.

   
   git commit -m "added access to $project_name" -a
   
   [master 2ded8a6] added access to new_zealand
    1 files changed, 1 insertions(+), 1 deletions(-)
   
   git push
   
   Counting objects: 5, done.
   Delta compression using up to 2 threads.
   Compressing objects: 100% (3/3), done.
   Writing objects: 100% (3/3), 332 bytes, done.
   Total 3 (delta 1), reused 0 (delta 0)
   To git@features.coders.co.nz:gitosis-admin.git
      58d0fe4..2ded8a6  HEAD -> master
   

   So now I should be allowed to write to a $project_name folder, next time I upload to the repo.
   Will gitosis now make the space for me?

   
   popd # (back in the project folder again)
   git push
   
   Initialized empty Git repository in /home/git/repositories/new_zealand.git/
   No refs in common and none specified; doing nothing.
   Perhaps you should specify a branch such as 'master'.
   fatal: The remote end hung up unexpectedly
   error: failed to push some refs to 'git@features.coders.co.nz:new_zealand.git'
   dan@reception:new_zealand $ 
   
   

   Oh yeah, at least the first time I must do it this way:

   
   git push origin master:refs/heads/master
   
   Counting objects: 11, done.
   Delta compression using up to 2 threads.
   Compressing objects: 100% (11/11), done.
   Writing objects: 100% (11/11), 47.60 KiB, done.
   Total 11 (delta 1), reused 0 (delta 0)
   To git@features.coders.co.nz:new_zealand.git
    * [new branch]      master -> master
   

   Hey, I think it worked!

6. Lets try a test.

   
   cd /tmp
   git clone git://features.coders.co.nz/$project_name
   
   Initialized empty Git repository in /private/tmp/new_zealand/.git/
   remote: Counting objects: 11, done.
   remote: Compressing objects: 100% (11/11), done.
   remote: Total 11 (delta 1), reused 0 (delta 0)
   Receiving objects: 100% (11/11), 47.58 KiB | 23 KiB/s, done.
   Resolving deltas: 100% (1/1), done.
   
   ls $project_name
   
   NZ_regions_with_geolocation.csv         new_zealand.features.inc                new_zealand.info
   new_zealand.features.taxonomy.inc       new_zealand.module                     NZ_suburbs_with_geolocation.csv         
   new_zealand.feeds_importer_default.inc
   
   

   Yep, I have a checkout, fetched from the remote repo.

Next steps

Pushing and checking out are working.. but hey, update is not. What's wrong?
Firstly, the command is not 'update', it should be

git pull

... just because git wants to use different names for common actions.

But I get:

You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
your configuration file does not tell me either.        Please
specify which branch you want to merge on the command line and
try again (e.g. 'git pull <repository> <refspec>').
See git-pull(1) for details.

If you often merge with the same branch, you may want to
configure the following variables in your configuration
file:

    branch.master.remote = <nickname>
    branch.master.merge = <remote-ref>
    remote.<nickname>.url = <url>
    remote.<nickname>.fetch = <refspec>

See git-config(1) for details.

Now, that particular lump of help was pretty obscure for me. Now, after figuring things out the hard way I can see what it's trying to say, but reading it on its own, it just doesn't make enough sense.

The interpretation is: that when you do a "git pull", it expects to be told where to pull things from. This can happen either

1. by entering the full remote URL and 'ref' each time. 'ref being (I think) something like a branch or version number
2. by entering a 'nickname' for the remote URL, and using the preferences (including a default ref) for that nickname, which are stored somewhere in some local configs
3. by telling your local configs to use a certain 'nicknamed' set of preferences by default most of the time, and don't ask all the time. This would be your normal assumption - but it's not enabled by default

It turns out that the magic words I really wanted were:

git pull origin master

Where 'origin' is the nickname for the remote server, which was set up earlier with the command:

git remote add origin git@features.coders.co.nz:$project_name.git

'master' , um, I dunno, but I guess it means the main branch of the code.

Now, as hinted at in the error message for git, I can set these to be defaults so it won't ask me again. What that message is trying to say is

1. Edit your local git config file. This is done by git config -e
2. Edit the settings in that file for the default nickname
   

   [remote "origin"]
             url = git@features.coders.co.nz:nzgls.git
             fetch = master
   

Entering a value of 'master' for 'fetch' in the section for 'origin' means that next time you fetch from 'origin' it will assume you want to fetch the 'master' version.

Yes, this is what we want.


Now, finally, we can just say

git pull


 * branch            master     -> FETCH_HEAD
Updating 00026b7..b8930ac
Fast forward
 nzgls.features.taxonomy.inc |    4 ----
 nzgls.info                  |    2 +-
 2 files changed, 1 insertions(+), 5 deletions(-)

Note that when I went to edit the config file, there was something odd in it.

[remote "origin"]
          url = git@features.coders.co.nz:nzgls.git
          fetch = "+refs/heads/*:refs/remotes/origin/*"

??? So, I tried working around it, got the syntax wrong, and eventually just replaced the 'fetch' line altogether.

A shorter way to do everything (now you know what is actually wanted) is just to go:

git config remote.origin.fetch master

... which edits the config value directly for you.