Problems setting up bare repository (git 1.5.3.3)

Problems setting up bare repository (git 1.5.3.3)

[Barry Fishman]

Using the 1.5.3.3 release:

$ cd /pub/git
$ mkdir foo.git
$ cd foo.git
$ git --bare init
Initialized empty Git repository in /pub/git/foo.git/
$ git --bare branch

Note that there is no master branch.

$ cd /some/git/workdir
$ git push /pub/git/foo.git master:master
error: dst refspec master does not match any existing ref on the remote and does not start with refs/.
fatal: The remote end hung up unexpectedly
error: failed to push to '/pub/git/foo.git'

$ git push --force /pub/git/foo.git master:master
error: dst refspec master does not match any existing ref on the remote and does not start with refs/.
fatal: The remote end hung up unexpectedly
error: failed to push to '/pub/git/foo.git'

$ git push --all /pub/git/foo.git
updating 'refs/heads/master'
  from 0000000000000000000000000000000000000000
  to   e623fb5ba6fac345eb6af552b40412acdc447b31
Generating pack...
Done counting 61 objects.
Deltifying 61 objects...
 100% (61/61) done
Writing 61 objects...
Unpacking 61 objects...
 100% (61/61) done
Total 61 (delta 31), reused 50 (delta 25)
 100% (61/61) done
refs/heads/master: 0000000000000000000000000000000000000000 -> e623fb5ba6fac345eb6af552b40412acdc447b31

But what if I have more branches and want to just push the master
branch?  This worked when I tried it last (probably 1.5.2.2).  This time
I had to "git push --all" and then delete all the unwanted branches.

-- 
Barry Fishman

Re: Problems setting up bare repository (git 1.5.3.3)

[Junio C Hamano]

Barry Fishman <barry_fishman@acm.org> writes:

> $ git push --force /pub/git/foo.git master:master
> error: dst refspec master does not match any existing ref on the remote and does not start with refs/.
> fatal: The remote end hung up unexpectedly
> error: failed to push to '/pub/git/foo.git'

Read BOTH OF the error messages.  Especially the first one.

This error message is telling you that the dst side of the
refspec you supplied (that's the second 'master' in
"master:master") does not exist there, and we do not create it
unless you give a full refname that begins with refs/ (so that
push can tell if you want to create a tag or a branch).

$ git push /pub/git/foo.git master:refs/heads/master

would have worked, without --force.

Re: Problems setting up bare repository (git 1.5.3.3)

[Carl Worth]

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

On Mon, 01 Oct 2007 15:32:58 -0700, Junio C Hamano wrote:
> "master:master") does not exist there, and we do not create it
> unless you give a full refname that begins with refs/ (so that
> push can tell if you want to create a tag or a branch).

And why is that?

Why isn't pushing a branch interpreted as wanting to create a branch
and pushing a tag interpreted as wanting to create a tag unless git is
told differently?

> $ git push /pub/git/foo.git master:refs/heads/master

I mean, it's nice that the advanced user can get all specific and
invoke the low-level refs/heads/ thing here. But what I'd really like
to have instead is just:

$ git push /pub/git/foo.git master

Is there any reason that that shouldn't be interpreted as
"master:master" and that that would in turn be interpreted as "create
a remote refs/heads/master" ?

That would really be much kinder for new users.

-Carl

PS. As someone who has written some new-user documentation for git,
there are a few low-level git notions that I would like to avoid in
that documentation. For example, one is FETCH_HEAD. In my first
attempt at porting hgbook-chapter2 to git I found myself using
FETCH_HEAD to simulate "hg incoming". Thankfully, I was able to
rewrite it by taking advantage of remotes and using "master..origin"
instead.

Another example is "refs/heads". I avoided this partially by inly
documenting how to push all branches with "--all", but I'd much rather
be able to say that the user could git push URL branch
another-branch..." or "git push URL --all" for convenience. Finally,
git-push itself spews quite a bit of output with "refs/heads" in it
that I don't think is useful at all. For talking with the user, git
should say "branch master" not "refs/heads/master".

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems setting up bare repository (git 1.5.3.3)

[J. Bruce Fields]

On Mon, Oct 01, 2007 at 04:06:09PM -0700, Carl Worth wrote:
> Another example is "refs/heads". I avoided this partially by inly
> documenting how to push all branches with "--all", but I'd much rather
> be able to say that the user could git push URL branch
> another-branch..." or "git push URL --all" for convenience. Finally,
> git-push itself spews quite a bit of output with "refs/heads" in it
> that I don't think is useful at all. For talking with the user, git
> should say "branch master" not "refs/heads/master".

I'd be nervous about skipping discussion of the refs/ namespace.  Sure,
introduce branch heads and tags on their own first, but you've got to
mention the rest pretty early on.  Eventually anyone can find themselves
with a tags, heads, and remotes with the same names, and then it's easy
to get stuck if you don't have a way to disambiguate.

And, really, it doesn't take that much space to explain this stuff.

--b.

Re: Problems setting up bare repository (git 1.5.3.3)

[Junio C Hamano]

Carl Worth <cworth@cworth.org> writes:

> On Mon, 01 Oct 2007 15:32:58 -0700, Junio C Hamano wrote:
>> "master:master") does not exist there, and we do not create it
>> unless you give a full refname that begins with refs/ (so that
>> push can tell if you want to create a tag or a branch).
>
> And why is that?

I think Daniel's rewrite of remote ref matching code that has
been cooking in 'next' changes the match semantics of the remote
side in subtle way to make it easier to favor branches when
pushing branches, but I juggle many topics and I have to go back
to the code to make sure.  Since you are interested, and more
importantly since I know you are capable to do the digging
yourself, I won't be doing the digging myself immediately,
though.

Re: Problems setting up bare repository (git 1.5.3.3)

[Shawn O. Pearce]

Carl Worth <cworth@cworth.org> wrote:
> $ git push /pub/git/foo.git master
> 
> Is there any reason that that shouldn't be interpreted as
> "master:master" and that that would in turn be interpreted as "create
> a remote refs/heads/master" ?

This is actually read more as:

 1) Expand "master" to "refs/heads/master"
 2) Expand "refs/heads/master" to "refs/heads/master:refs/heads/master"

We first try to expand the local name to an "absolute" local name,
then if the remote name is missing default it to the same as the
(now expanded) local name.  So "push origin master" is not read as
"push origin refs/haeds/master:master".

> PS. As someone who has written some new-user documentation for git,
> there are a few low-level git notions that I would like to avoid in
> that documentation. For example, one is FETCH_HEAD. In my first
> attempt at porting hgbook-chapter2 to git I found myself using
> FETCH_HEAD to simulate "hg incoming". Thankfully, I was able to
> rewrite it by taking advantage of remotes and using "master..origin"
> instead.

How about:

  git config alias.incoming 'log ..FETCH_HEAD'

?  Or do we need --reverse in there too to simulate "hg incoming"?
The thing is, FETCH_HEAD is a lot more powerful than a tracking
branch.  It can contain objects randomly pulled from another
repository (e.g. one shot pulls).
 
> Another example is "refs/heads". I avoided this partially by inly
> documenting how to push all branches with "--all", but I'd much rather
> be able to say that the user could git push URL branch
> another-branch..." or "git push URL --all" for convenience. Finally,
> git-push itself spews quite a bit of output with "refs/heads" in it
> that I don't think is useful at all. For talking with the user, git
> should say "branch master" not "refs/heads/master".

Agreed.  We do that in fetch.  We should do that in push.  We should
only mention "refs/*" if the user is pushing something funny, e.g.
pushing into the remote tracking branch space.  Or the stash.  Etc.
Tags and normal branches should be denoted as such.

-- 
Shawn.

Re: Problems setting up bare repository (git 1.5.3.3)

[Carl Worth]

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

On Mon, 01 Oct 2007 16:24:09 -0700, Junio C Hamano wrote:
> I think Daniel's rewrite of remote ref matching code that has
> been cooking in 'next' changes the match semantics of the remote
> side in subtle way to make it easier to favor branches when
> pushing branches, but I juggle many topics and I have to go back
> to the code to make sure.  Since you are interested, and more
> importantly since I know you are capable to do the digging
> yourself, I won't be doing the digging myself immediately,
> though.

Great. I'll go looking for that.

And if I don't find what I'm thinking of there, I'll see if I can't
cook up something else myself.

Thanks again,

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems setting up bare repository (git 1.5.3.3)

[Johannes Schindelin]

Hi,

On Mon, 1 Oct 2007, Carl Worth wrote:

> On Mon, 01 Oct 2007 15:32:58 -0700, Junio C Hamano wrote:
> > "master:master") does not exist there, and we do not create it
> > unless you give a full refname that begins with refs/ (so that
> > push can tell if you want to create a tag or a branch).
> 
> And why is that?

Well, if the OP had used "git push <bla> master" instead of 
"... master:master", it would have worked.  I am unaware of any tutorial 
that suggests the latter, only of tutorials that suggest the former.

Ciao,
Dscho

Re: Problems setting up bare repository (git 1.5.3.3)

[Barry Fishman]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Well, if the OP had used "git push <bla> master" instead of 
> "... master:master", it would have worked.  I am unaware of any tutorial 
> that suggests the latter, only of tutorials that suggest the former.

I did recheck the tutorials, and did not find the code I was
using.  So there was nothing incorrect in the documentation.

As for "master working where "master:master" didn't, this only exposes a
more complex set of rules.  I was not hoping for a more complex set of
rules to learn, as GIT tried to figure out what I meant.  I was hoping
for a simpler command that did what I told it to do, and I was given it
by Junio Hamano.

What distracted me was that after the "git --bare init", there seemed to
be a incompletely defined setup.  This sent me down the wrong path.

Although there was a master branch to which HEAD pointed, there was no
ref/heads/master file or even a "packed-refs".  This also confuses the
the "git branch" command, so that when I initial tried "git --bare
branch" it seemed unaware of any master branch.  I then tried:

$ git --bare branch refs/heads/master
fatal: Not a valid object name: 'master'.

If there isn't an initial master branch, then shouldn't "git branch" be
able to create one.  And if there is one, shouldn't the automatic rules
explained in git-rev-parse man page find it?  The error messages from
the branch command is what got me on the wrong logical path.

The man page for git-init says:

  This command creates an empty git repository - basically a .git directory
  with subdirectories for objects, refs/heads, refs/tags, and template
  files. An initial HEAD file that references the HEAD of the master branch
  is also created.

Which is true, but although there is a HEAD that references the
master branch, there isn't really any master branch.  It might
say something like:

  This command creates an empty git repository - basically a .git directory
  with subdirectories for objects, refs/heads, refs/tags, and template
  files. An initial HEAD file references the refs/heads/master branch
  which is created with the first commit.

This would at least somewhat explain "git branch" results.

The man page for git-push seems clear to me now.  I should have
more closely read the last example.  The first example might
be changed to say:

git push origin master
    Find a ref that matches master in the source repository (most
    likely, it would find refs/heads/master), and update (or create) the
    same ref, refs/heads/master, in the origin repository with it.

-- 
Barry Fishman

Re: Problems setting up bare repository (git 1.5.3.3)

[Carl Worth]

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

On Tue, 2 Oct 2007 10:46:56 +0100 (BST), Johannes Schindelin wrote:
> On Mon, 1 Oct 2007, Carl Worth wrote:
> > And why is that?
>
> Well, if the OP had used "git push <bla> master" instead of
> "... master:master", it would have worked.  I am unaware of any tutorial
> that suggests the latter, only of tutorials that suggest the former.

OK. I was wrong. Somehow I got stuck thinking that "git push <bla>
master" wouldn't create a new remote master branch if it didn't
previously exist. (It's bizarre that I forgot since I've used that for
a long time).

Sorry about the noise.

-Carl

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Problems setting up bare repository (git 1.5.3.3)

[Johannes Schindelin]

Hi,

[please do not cull me from the Cc: list, especially when you are quoting 
me]

On Tue, 2 Oct 2007, Barry Fishman wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > Well, if the OP had used "git push <bla> master" instead of "... 
> > master:master", it would have worked.  I am unaware of any tutorial 
> > that suggests the latter, only of tutorials that suggest the former.
> 
> I did recheck the tutorials, and did not find the code I was
> using.  So there was nothing incorrect in the documentation.

Good.  Just for my curiousity: where in the documentation did you look for 
help?  (We might want to advertise "git push <nick> <branch>" more loudly 
there.)

> What distracted me was that after the "git --bare init", there seemed to 
> be a incompletely defined setup.  This sent me down the wrong path.
> 
> Although there was a master branch to which HEAD pointed, there was no
> ref/heads/master file or even a "packed-refs".

That means that there was no master branch.  Before the first commit, a 
branch does not exist.  We are stricter in that regard than other SCMs.

> If there isn't an initial master branch, then shouldn't "git branch" be
> able to create one.

Why?  I really do not see the point in creating a branch which is named 
different than "master", when you have nothing to begin with.

Just use "master".  As easy as that.

If you really have to paint the bike shed, you can always rename your 
branch later, when you got something, by "git branch -m <new-branch-name>".

>   This command creates an empty git repository - basically a .git directory
>   with subdirectories for objects, refs/heads, refs/tags, and template
>   files. An initial HEAD file references the refs/heads/master branch
>   which is created with the first commit.

How about "Your first commit will create the master branch" instead of the 
last sentence?

Ciao,
Dscho

Re: Problems setting up bare repository (git 1.5.3.3)

[Johannes Schindelin]

Hi,

On Tue, 2 Oct 2007, Carl Worth wrote:

> On Tue, 2 Oct 2007 10:46:56 +0100 (BST), Johannes Schindelin wrote:
> > On Mon, 1 Oct 2007, Carl Worth wrote:
> > > And why is that?
> >
> > Well, if the OP had used "git push <bla> master" instead of "... 
> > master:master", it would have worked.  I am unaware of any tutorial 
> > that suggests the latter, only of tutorials that suggest the former.
> 
> OK. I was wrong. Somehow I got stuck thinking that "git push <bla> 
> master" wouldn't create a new remote master branch if it didn't 
> previously exist. (It's bizarre that I forgot since I've used that for a 
> long time).
> 
> Sorry about the noise.

Nothing to be sorry about.  It got me thinking.  People propose that "git 
push <nick> master:blub" should create the branch "refs/heads/blub" on the 
remote side.

My initial reaction was "then you have to be precise, because we do not 
know if you want to push it as a branch, or as a lightweight tag".

But then I stepped back a little: What is most likely meant when you say 
"master:blub" and there is no tag/branch of name "blub" on the remote 
side?  Exactly, you want a branch to be created.

_Except_ if you had a typo, such as "git push ko master:po" where you want 
to be warned that that ref is not present on the remote side.

So I am less opposed to making "master:blub" automatically create a branch 
"blub" if it does not exist yet.  But opposed nevertheless.

Ciao,
Dscho

Re: Problems setting up bare repository (git 1.5.3.3)

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> But then I stepped back a little: What is most likely meant when you say 
> "master:blub" and there is no tag/branch of name "blub" on the remote 
> side?  Exactly, you want a branch to be created.

It's not that "exactly" for me.

If your push were "next~27^2:frotz", it becomes even less clear.
It may be that I am pushing out the tip of a topic branch I
usually do not push out, so it would be easier for some specific
person to build on top of.  Or maybe I am marking that place as
a lightweight tag.  They are equally likely.

On the other hand, what the user wants to do with "git push
$elsewhere frob" is reasonably clear.  If frob is locally a
branch, then the branch is pushed out.  If frob is a tag, the
tag is propagated.

Re: Problems setting up bare repository (git 1.5.3.3)

[Sean]

On Tue, 02 Oct 2007 11:23:39 -0700
Junio C Hamano <gitster@pobox.com> wrote:

> If your push were "next~27^2:frotz", it becomes even less clear.
> It may be that I am pushing out the tip of a topic branch I
> usually do not push out, so it would be easier for some specific
> person to build on top of.  Or maybe I am marking that place as
> a lightweight tag.  They are equally likely.

But you could pick a reasonable default in assuming that a new
branch is desired with the above example.  If someone wants to
push a tag, they can create the tag locally, and then push it.

Sean

Re: Problems setting up bare repository (git 1.5.3.3)

[Junio C Hamano]

Sean <seanlkml@sympatico.ca> writes:

> On Tue, 02 Oct 2007 11:23:39 -0700
> Junio C Hamano <gitster@pobox.com> wrote:
>
>> If your push were "next~27^2:frotz", it becomes even less clear.
>> It may be that I am pushing out the tip of a topic branch I
>> usually do not push out, so it would be easier for some specific
>> person to build on top of.  Or maybe I am marking that place as
>> a lightweight tag.  They are equally likely.
>
> But you could pick a reasonable default in assuming that a new
> branch is desired with the above example.  If someone wants to
> push a tag, they can create the tag locally, and then push it.

I think you are on the same page.

We can pick _a_ default, and tell people that if they want a
non-default behaviour, they have to be explicit.  That goes
without saying.

The discussion between Johannes and I was about picking what
default is _reasonable_; Johannes made it sound like branches
are norm and tags are oddball.  I was merely pointing out that
it won't be so cut-and-dried.

Re: Problems setting up bare repository (git 1.5.3.3)

[Barry Fishman]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Tue, 2 Oct 2007, Barry Fishman wrote:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > Well, if the OP had used "git push <bla> master" instead of "... 
>> > master:master", it would have worked.  I am unaware of any tutorial 
>> > that suggests the latter, only of tutorials that suggest the former.
>> 
>> I did recheck the tutorials, and did not find the code I was
>> using.  So there was nothing incorrect in the documentation.
>
> Good.  Just for my curiousity: where in the documentation did you look for 
> help?  (We might want to advertise "git push <nick> <branch>" more loudly 
> there.)

I'm not sure, but I think I got the idea from:
  http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
which does a fetch while in the bare repository rather than a push into
it:

  $ mkdir /pub/my-repo.git
  $ cd /pub/my-repo.git
  $ git --bare init --shared
  $ git --bare fetch /home/alice/myproject master:master

That series of commands works.

>> If there isn't an initial master branch, then shouldn't "git branch" be
>> able to create one.
>
> Why?  I really do not see the point in creating a branch which is named 
> different than "master", when you have nothing to begin with.

You are right, of course.  I was just following a line of thought, not
implying that creating such a branch was ever reasonable to do.

>>   This command creates an empty git repository - basically a .git directory
>>   with subdirectories for objects, refs/heads, refs/tags, and template
>>   files. An initial HEAD file references the refs/heads/master branch
>>   which is created with the first commit.
>
> How about "Your first commit will create the master branch" instead of the 
> last sentence?

Yes.  Less wobbly than how I worded it.

-- 
Barry Fishman

Re: Problems setting up bare repository (git 1.5.3.3)

[Johannes Schindelin]

Hi,

On Tue, 2 Oct 2007, Sean wrote:

> On Tue, 02 Oct 2007 11:23:39 -0700
> Junio C Hamano <gitster@pobox.com> wrote:
> 
> > If your push were "next~27^2:frotz", it becomes even less clear. It 
> > may be that I am pushing out the tip of a topic branch I usually do 
> > not push out, so it would be easier for some specific person to build 
> > on top of.  Or maybe I am marking that place as a lightweight tag.  
> > They are equally likely.
> 
> But you could pick a reasonable default in assuming that a new branch is 
> desired with the above example.  If someone wants to push a tag, they 
> can create the tag locally, and then push it.

And if someone wants to push a branch, they can create the branch locally, 
and then push it.  (Your last sentence with s/tag/branch/g applied.)

Ciao,
Dscho

Re: Problems setting up bare repository (git 1.5.3.3)

[Johannes Schindelin]

Hi,

On Tue, 2 Oct 2007, Junio C Hamano wrote:

> The discussion between Johannes and I was about picking what default is 
> _reasonable_; Johannes made it sound like branches are norm and tags are 
> oddball.  I was merely pointing out that it won't be so cut-and-dried.

Actually, I had Carl Worth in mind when I asked the (rhetorical) question 
what is meant by "master:blub".  And I think Carl agrees that he would 
expect it to create a new branch.

However, as I hope I made clear that I do not think that a DWIMery would 
do good here.  IOW I vote for keeping the existing behaviour (otherwise 
you'd have seen a patch from me, too).

Ciao,
Dscho