Possible to make a totally empty repository for remote access?

Possible to make a totally empty repository for remote access?

[Wincent Colaiuta]

For a new project (no code yet) I wanted to make an empty, bare  
repository (no working copy) on a remote public server as a starting  
point, clone it locally, and gradually create content locally and  
push it out to the remote, public server.

But so far I've been unable to do so in a straightfoward fashion...

mkdir test.git
cd test.git
git --bare init
touch git-daemon-export-ok

If I try to clone such an empty repository I get:

fatal: no matching remote head

And GIT_DIR/HEAD points to refs/heads/master, which doesn't exist yet.

Same if I go for a non-bare, but still empty repository:

mkdir test
cd test
git init
touch .git/git-daemon-export-ok

Only after adding actual content can I clone without getting the "no  
matching remote head" error:

echo "foo" > bar
git add bar
git commit -m "foobar"

Then cloning works.

I understand that Git is a *content* manager and a totally empty  
repository has no content, and therefore no tree object which the  
HEAD can point to. But the trouble with adding content the way I  
describe above, is that my public repository is no longer bare; it  
now has a working copy, which I didn't really want.

What's the way around this? Do I start with a non-bare repository,  
add any old bogus content, and then convert it to bare and blow away  
the working copy?

mkdir test
cd test
git init
touch .git/git-daemon-export-ok
touch .gitignore
git add .gitignore
git commit -m "Initial empty repository containing only an  
empty .gitignore file"
git config core.bare true
mv .git ../test.git
cd ..
rm -r test

Is there a better way? Am I missing something obvious?

Cheers,
Wincent

Re: Possible to make a totally empty repository for remote access?

[Junio C Hamano]

Wincent Colaiuta <win@wincent.com> writes:

> I understand that Git is a *content* manager and a totally empty
> repository has no content, and therefore no tree object which the
> HEAD can point to. But the trouble with adding content the way I
> describe above, is that my public repository is no longer bare; it
> now has a working copy, which I didn't really want.

You prepared an empty bare repository for publishing, and that
is very good.

The next step is that you prepare your contents elsewhere.  That
would be your private working place, i.e. the place you would
normally work in).  You push from your private working place
into that publishing repository.  Your working place is where
the very initial commit should come from, since you are the one
who is starting the project.

Note that the private working place does not have to be a clone
of the empty one.  That actually is backwards.  Your work
started from your private working place to the publishing one.

You could even clone your private repository to publishing one
to make it clear who is the master and who is the copy if you
wanted to, but because you already have the bare repository for
publishing, just pushing into it is all that is needed.

Re: Possible to make a totally empty repository for remote access?

[Wincent Colaiuta]

El 14/7/2007, a las 0:18, Junio C Hamano escribió:

> Note that the private working place does not have to be a clone
> of the empty one.  That actually is backwards.  Your work
> started from your private working place to the publishing one.

Thanks very much for the clarification, Junio. I didn't realize I  
could push like that (thought it had to be from a clone); that's very  
flexible indeed.

For the benefit of others who might stumble across this question in  
the archives, the basic pattern is:

# create the bare, empty public repository on the remote server:
mkdir test.git
cd test.git
git --bare init
touch git-daemon-export-ok

# locally, create some initial content
mkdir test
cd test
git init
vi foobar # etc
git add .
git commit -s
git tag -s v0.0.1

# push initial contents
git push git.server.example.com:/pub/git/test.git master

This assumes that you have git-daemon set up to provide public read- 
only access, and appropriate SSH accounts and configuration for those  
who need write access, but that's all fairly well documented  
elsewhere (ie in the git-daemon man page, and in abundant information  
on the web about setting up SSH access with public-key auth).

To make such pushes easier in the future you can create a local  
shortcut file, .git/remotes/shortcut (or similar), with contents like:

URL: git.server.example.com:/pub/git/test.git
Push: master

If other developers will have write access to the remote repo then  
you can add "Pull:" statements as well so as to keep up to date (as  
detailed in the git-push man page, and in the "Everyday GIT With 20  
Commands Or So" document: <http://www.kernel.org/pub/software/scm/git/ 
docs/everyday.html>), and you can synchronize multiple branches in  
both directions by adding additional "Push:" and "Pull:"  
declarations. With the shortcut file in place you could have written  
the above push as:

git push shortcut

To push your initial tag you would do:

git push shortcut v.0.0.1

(Or you could have included the tag in the original push by passing  
the --tags switch.)

One thing to note: the ".git/remotes/shortcut" file should not be  
confused with the directories under ".git/refs/remotes".

Finally, now that the remote repository actually has some content in  
it you also have the option of just creating a fresh local clone of  
it, and thus benefitting from the automatic set-up that "git clone"  
does for you:

git clone git://git.server.example.com/test

The Git documentation is shockingly good; almost too good: there is  
so much of it that sometimes it can be hard to find exactly what  
you're looking for. For reference, the "Git core tutorial for  
developers" was the one place which I could find which explicitly  
talked about the missing piece of the puzzle: pushing from a private  
repo (not a clone) to an empty public one:

<http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html>

Cheers,
Wincent

Re: Possible to make a totally empty repository for remote access?

[Jeff King]

On Sat, Jul 14, 2007 at 04:19:41AM +0200, Wincent Colaiuta wrote:

> To make such pushes easier in the future you can create a local shortcut 
> file, .git/remotes/shortcut (or similar), with contents like:
>
> URL: git.server.example.com:/pub/git/test.git
> Push: master

The "new" way (by "new" I mean available for over a year, since v1.4.1)
is to put such configuration into your .git/config file:

[remote "shortcut"]
  url = git.server.example.com:/pub/git/test.git

Though if this is going to be the upstream from which you will be
pushing and pulling, you may want to call it "origin" (which will make
it the default for pushing and pulling).

Even more simply, you can get the same remote config that git-clone
would have set up by using the git-remote command:

  $ git-init
  $ git-remote origin server:/pub/git/test.git

-Peff

Re: Possible to make a totally empty repository for remote access?

[Jeff King]

On Fri, Jul 13, 2007 at 10:58:19PM -0400, Jeff King wrote:

>   $ git-remote origin server:/pub/git/test.git

Sorry, this should be:

  git-remote add origin server:/pub/git/test.git

-Peff

Re: Possible to make a totally empty repository for remote access?

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 536 bytes --]

also sprach Jeff King <peff@peff.net> [2007.07.14.0458 +0200]:
> The "new" way (by "new" I mean available for over a year, since v1.4.1)
> is to put such configuration into your .git/config file:

Have a look also at

  http://blog.madduck.net/vcs/2007.07.11_publishing-git-repositories

-- 
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
 
spamtraps: madduck.bogus@madduck.net
 
it is ok to let your mind go blank,
but please turn off the sound.

[-- Attachment #2: Digital signature (GPG/PGP) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]