I thougth I could create a new branch on the server using:

# > git push ssh://devsrv/var/git/os2kernel.git linus:refs/linus
Warning: No xauth data; using fake authentication data for X11 forwarding.
updating 'refs/linus' using 'refs/heads/linus'
 from 0000000000000000000000000000000000000000
 to bbf25010f1a6b761914430f5fca081ec8c7accd1
Generating pack...
Done counting 0 objects.
Writing 0 objects...
Total 0 (delta 0), reused 0 (delta 0)
error: refusing to create funny ref 'refs/linus' locally
ng refs/linus funny refname
error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'

but that doesn't work. Am I doing this wrong?

git 1.5.3.4
 
   Jocke

-

Include 'heads' in your remote refspec:

    git push ssh://devsrv/var/git/os2kernel.git linus:refs/heads/linus

You may need to cleanup though. I'm not sure if the remote side
already created 'refs/linus'. The error message only indicates that
locally git refused to create the "funny refname". Pushing a refspec
with an empty local part should delete the "funny refname" on the
remote:

    git push ssh://devsrv/var/git/os2kernel.git :refs/linus

Did this solve your problem?

	Steffen
-

Cute.  The error message "error: refusing to create .. locally"
is actually coming from the remote site.  Locally here is
actually remotely.  We *really* should change that.  Its l.169 of
receive-pack.c, which is only running on the remote side.  :)

Anyone game to improve that error message?  Should be a pretty
simple patch.  One of the may low-hanging fruits in Git.

-- 
Shawn.
-

Just gave it a try, using git sendmail. Hopefully it will
reach the list :)

-

Now the push went OK:
git push  ssh://devsrv/var/git/os2kernel.git linus:refs/head/linus
Warning: No xauth data; using fake authentication data for X11 forwarding.
updating 'refs/head/linus' using 'refs/heads/linus'
  from 0000000000000000000000000000000000000000
  to   bbf25010f1a6b761914430f5fca081ec8c7accd1
Generating pack...
Done counting 0 objects.
Writing 0 objects...
Total 0 (delta 0), reused 0 (delta 0)
refs/head/linus: 0000000000000000000000000000000000000000 -> bbf25010f1a6b761914430f5fca081ec8c7accd1

but there is no linus branch in the server repo!

However:
 git push  ssh://devsrv/var/git/os2kernel.git linus

creates a linus branch in the server and 

 git push  ssh://devsrv/var/git/os2kernel.git :linus
 Warning: No xauth data; using fake authentication data for X11 forwarding. 
 deleting 'refs/heads/linus'
 refs/heads/linus: bbf25010f1a6b761914430f5fca081ec8c7accd1 -> deleted
 Everything up-to-date

deletes the linus branch on the server and so does
git push  ssh://devsrv/var/git/os2kernel.git :refs/heads/linus

ahh, now I see. When creating the branch the refspec needs to be refs/heads/linus,
not refs/head/linus

refs/head/linus will create just that on the server. git branch does not look
there, only in refs/heads

Seems like it is a bit too easy to make mistakes here. Why can I delete
a branch with :linus but not create one with linus:linus?
Also confusing that git lets me create refs/head/linus when git branch
cannot find it.

-

Hi,


I wonder why you bother with the colon at all.  Just

	git push <remote> linus

and be done with it.  The colon is only there to play interesting games, 
not something as simple as "push this branch" or "push this tag".

Ciao,
Dscho

-

First, I didn't know that I could do that.
Secondly, I was also looking do v2.6.23:linus refspecs

 Jocke 
-

Hi,



First, then our documentation could be better.  How?

Second, why not "git checkout -b linus v2.6.23 && git push origin linus"?

Ciao,
Dscho

-

Well, it isn't clear to me how all this is supposed to work and
what is bugs. Clearifying that would help.

For instances I did a push with v2.6.23:refs/heads/linus and now
I got a branch with the SHA1 of v2.6.23 tag(0b8bc8b91cf6befea20fe78b90367ca7b61cfa0d)

An extra checkout that takes time but works. Doesn't make the above
"weiredness" go away though.

-

Hi,


It strikes me as really odd that you would _want_ to create a branch 

Not only that: before trying to publish something, I would have expected 

Yes it does.

git checkout -b <branchname> resolves to the commit that the tag pointed 
to.  So it would not push a tag, which you did.

Of course you could do what you planned to do, if you knew git better.  
But you are not familiar enough with git's inner workings yet, so I 
suggest to stay with things for now that work _always_, and exactly as 
expected.

Such as creating a branch locally, with exactly the name that you plan it 
to have remotely, and then pushing it with "git push origin <branchname>".  
Easy as apple pie.

Ciao,
Dscho

-

It strikes me as really odd that a core developers like yourself
hasn't tried to justify/explain why push works as it does.

As I am trying to convince our dev. group here to move to git instead of subversion, I
need to learn how git works. Now I have gotten to the push function and I need
to know what can be done with push and how, pitfalls too. As I go along I find behavior
that I find odd and report these to the list.

 git push <repo> v2.6.23:refs/heads/linus
will make a tag look like a branch

 git push <repo> linus:linus
won't let me create the remote branch linus but
 git push <repo> linus
will

 git push <repo> :linus
OOPS, now I just deleted remote branch linus, no warning
 
 git push <repo> linus:refs/head/linus
creates a branch that is invisible(wont show in git branch -a)

 git push <repo> linus:refs/heads/newbranch
creates remote branch newbranch, but you have to know the magic words
refs/heads/ to do it.


No it doesn't. If someone else in my group wants to create a branch they

-

That's becasue tags come in two flavors -- annotated and unannotated.
Annotated ones don't point to commits directly, but via 'tag' objects, that
contain description and usually signature.

Now git push will simply assign a remote branch whatever value you give it.

Because in the former you are not saying whether refs/heads/linus,
refs/tags/linus or something else (the fact that heads and tags are treated
specially by git does not mean refs can't have other subdirectories -- it
can).

On the other hand in the later it resolves the ref locally and uses the same

Your commands are quite obvious. No need for warning. (Besides, isn't there

It does not create a branch. It creates a ref with slightly funny name (it's
refs/heads, not refs/head).

Because you could have wanted a tag. Or a remote. Or something completely
different, maybe because some add-on uses (eg. stgit uses refs/bases and

To me it all looks perfectly consistent. But maybe the documentation should
state more clearly, that push works in terms of arbitrary refs, NOT branche=
s.
Feel free to post a documentation patch (people who just had hard time
finding something out are usually better at explaining it than old-timers w=
ho
consider it obvious).

--=20
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Hi,


Well, I explained that I think the "src:dst" way to specify things are not 
meant for git newbies.  Don't use it.

git push <remote> <branchname> works exactly as advertised.  It pushes the 







Yes.


Yes, it does.  You no longer can push a tag onto a remote branch by 
accident.  Just don't use the src:dest notation.  Forget about it.  You 
definitely don't need it before you understand git better.

Hth,
Dscho

-

But you need a full refspec starting with 'refs/heads/' if you want to
create a new branch on the remote side.

	Steffen

-

Hi,


No.  Not if the name is the same on the local side.

Ciao,
Dscho

-

You're right. The documentation of git-send-pack says what you're
saying:

'''
When one or more <ref> are specified explicitly, it can be either a  
single pattern, or a pair of such pattern separated by a colon  
":" (this means that a ref name cannot have a colon in it). A single  
pattern <name> is just a shorthand for <name>:<name>
'''

Here it says that <name> is a shorthand for <name>:<name>.
An later it states

'''
If <dst> does not match any remote ref, either
    * it has to start with "refs/"; <dst> is used as the destination  
literally in this case.
    * <src> == <dst> and the ref that matched the <src> must not  
exist in the set of remote refs; the ref matched <src> locally is  
used as the name of the destination.
'''

If <src> == <dst> then <dst> will be created even if it didn't exist.

I think the current implementation though is a bit different.
It will created a new branch for a colon-less refspec, that is

    git push origin work/topic

will create a new ref on the remote. But

    git push origin work/topic:work/topic

will _not_.


Until you corrected me, I believed that new branches will never
be created on the remote side unless a full ref is used. That is
I expected that only

    git push origin refs/heads/work/topic

would work.

I thought this would be another safety net -- kind of a reminder
not to push the wrong branch by accident.

I still like the idea, but apparently git didn't ever support what
I thought it would.

Maybe adding some command line flags making the different tasks
explicit could help:

     git push --create origin work/new-topic
     git push --delete origin work/old-topic
     git push --non-standard origin refs/funny/ref

We already have similar flags

     --all: all branches
     --tags: all tags
     --force: force non-fast-forward.

I haven't fully thought this through. Maybe I'll come up with a ...
[ message continues ]

This makes much more sense than the current method, thanks.

 Jocke

-

Shawn,
sp/push-refspec definitely needs more work (see below).



And I even fixed the behavior to match my expectation in a patch
which made it to spearce/pu:


d869233c62688742968663c4e8b5ff20a50a5011

     push, send-pack: fix test if remote branch exists for colon-less  
refspec

     A push must fail if the remote ref does not yet exist and the  
refspec
     does not start with refs/. Remote refs must explicitly be  
created with
     their full name.

     This commit adds some tests and fixes the existence check in  
send-pack.


sp/push-refspec definitely needs some more work.

	Steffen


-

BTW this does not work either:

git reset --hard HEAD^
git push -f  ssh://devsrv/var/git/os2kernel.git +master:master
updating 'refs/heads/master'
  from 9c344d18d01221c8f25080cb58910e6b09efbf55
  to   5761a9e5924b34615c748fba2dcb977ed04c1243
Generating pack...
Done counting 0 objects.
Writing 0 objects...
Total 0 (delta 0), reused 0 (delta 0)
error: denying non-fast forward refs/heads/master (you should pull first)
ng refs/heads/master non-fast forward
error: failed to push to 'ssh://devsrv/var/git/os2kernel.git'

I thought the + in +master:master and the -f option should let me
do that.
-

Yes, but its only on the client side.

See when we do a push the local client side determines if the push is
going to be a fast-forward or not.  If it isn't then the git-push
client aborts before it even uploads data to the remote side.
The --force or + can be used to make the client side skip this
check and just plow forward anyway.

But the remote side can also veto a non-fast-forward update.  By
default it refuses to allow such updates as they can orphan commits
(and thus potentially lose important work).  See the config option
receive.denyNonFastForwards; you may want to set this to true in
the remote side's config file.

-- 
Shawn.
-

I absolutely agree. But I'm not sure if those who use git since the
ancient days do agree too.
	
	Steffen
-