Publishing Question: First time Pushing to nonexsiting directory

Hello, I thought that there is a command available which I can use to push a repository to a remote nonexisting location (that gets created on the fly) like in the following scenario:

        - Create a git project on my laptop
        - Check in a few files
        - Publish the git repository to 

        (thinkpad) [~/work/astro-tg] git push 131.188.30.59:/home/cip/adm/sithglan/work/repositories/private/astro/
        fatal: '/home/cip/adm/sithglan/work/repositories/private/astro': unable to chdir or not a git archive
        fatal: The remote end hung up unexpectedly

I thought that I read a comment from Linus(?) long time ago to how to obtain that. But I am unable to find the e-mail in my archives. If there is no standard way, how do you do it? Just rsync the files and change the 'origin'?

        Thomas

Thomas Glanzmann <thomas@glanzmann.de> wrote:

SSH into the remote system that you want to push to, then run init-db there:

  $ ssh 131.188.30.59 git --git-dir=/home/cip/adm/sithglan/work/repositories/private/astro.git init-db

Configure that as a remote, e.g. origin:

  $ git remote add origin 131.188.30.59:/home/cip/adm/sithglan/work/repositories/private/astro.git

Now push to there:

  $ git push origin master:master

And maybe fetch back to create the tracking branches:

  $ git fetch

Note that in my examples above I added ".git" to the end of the repository path, as this is rather typical for a 'bare repository' (that is, a repository without a working directory attached). You usually don't want to push into a repository with a working directory, but it is supported and a lot of folks do it.

I also assumed Git 1.5.0 on your thinkpad end, as git-remote was recently added in that version. Handy tool. :)

Hallo Shawn,

thank you a lot. I just got home where I have internet connectivity with my laptop and tried your tips. That was by the way exactly I was looking for. Thank you a lot. However, I got a little problem. Here is the output:

        (thinkpad) [~/work/astro] ssh 131.188.30.59 git --git-dir=/home/cip/adm/sithglan/work/repositories/private/astro.git init-db
        (thinkpad) [~/work/astro] git remote add origin 131.188.30.59:/home/cip/adm/sithglan/work/repositories/private/astro.git
        (thinkpad) [~/work/astro] git push origin master:master
        updating 'refs/heads/master'
        from 0000000000000000000000000000000000000000
        to   7a04a7eb87797c4a5e8a6c4892d68862f202b2e2
        Generating pack...
        Done counting 30 objects.
        Deltifying 30 objects.
        100% (30/30) done
        Writing 30 objects.
        100% (30/30) done
        Total 30 (delta 7), reused 0 (delta 0)
        Unpacking 30 objects
        refs/heads/master: 0000000000000000000000000000000000000000 -> 7a04a7eb87797c4a5e8a6c4892d68862f202b2e2
        (thinkpad) [~/work/astro] git pull
        * refs/remotes/origin/master: storing branch 'master' of 131.188.30.59:/home/cip/adm/sithglan/work/repositories/private/astro
        commit: 7a04a7e
        Warning: No merge candidate found because value of config option
                "branch.master.merge" does not match any remote branch fetched.
        No changes.
        (thinkpad) [~/work/astro] git pull
        Warning: No merge candidate found because value of config option
                "branch.master.merge" does not match any remote branch fetched.
        No changes.

Maybe it is related to the fact that git version 1.4.4.4 is running on faui00u (131.188.30.59).

        Thomas

Thomas Glanzmann <thomas@glanzmann.de> wrote:

Good, the tracking branch was automatically created.

Check your .git/config. There is no configuration describing what to do when `git pull` is invoked on your master branch. You may want to add something like the following to your .git/config:

	[branch "master"]
		remote = origin
		merge = refs/heads/master

This just says that by default, `git pull` will merge the master branch of remote origin when you are on branch master.

Nope. It has to do with the fact that you are running 1.5.0 on your thinkpad and are missing the branch.master.merge entry noted above.

Hello Shawn,

I see.

Thanks. I added the lines and it doesn't give me the warning anylonger:

        (thinkpad) [~/work/astro] git pull
        Already up-to-date.

I see. Thanks for the awareness training.

        Thomas

Thomas Glanzmann <thomas@glanzmann.de> writes:

Sorry, there isn't.

What you remember might be this one:

    http://thread.gmane.org/gmane.comp.version-control.git/31351/focus=31610

Even if it isn't, it is worth a read. Look for "The creation of a new archive tends to" and "really _has_ to be separate".

There was another discussion around this topic as well:

    http://thread.gmane.org/gmane.comp.version-control.git/32040/focus=32108

which I think is a possible design in the right direction, but I did not hear much from the users (as you can see in the archive link above) so it hasn't materialized. The only real improvement that came out of the thread is deletion of a branch at the remote site with "git-push :refs/heads/to-be-removed".

Another ancient one is:

    http://thread.gmane.org/gmane.comp.version-control.git/12651/focus=12667