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
-

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.

-

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
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".

Hi,
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
-

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

Hi,
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
-

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.
-

On Tue, 02 Oct 2007 11:23:39 -0700
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

-

Hi,
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
-

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.
-

Hi,
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
-

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
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
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.

-

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

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.

-