On 17.10.2008, at 15:30, szimek wrote:
> On Thu, Oct 16, 2008 at 10:54 AM, Matt Todd <[EMAIL PROTECTED]>
> wrote:
>>
>> You can push up branches to create remote branches. This is a great
>> way to store in-development changes that *will* get merged back into
>> master, and makes sharing the code trivial.
>>
>
> What about branches that won't necessarily be merged back into master
> - i.e. if someone is writing some experimental code?

As long as you don't mind the code being visible to everyone who has  
access to the repo, I don't see a problem with it. Deleting (remote)  
branches is easy.

Or do you mean something else?

> In the article
> that you posted link to, there's this unintuitive command to remove
> remote branches, so is it a problem?

Why is it unintuitive? If you read up on the syntax for the push  
command, you'll see that on the left side of the colon is the source,  
and on the right side the destination. If you then push and use  
nothing as the source, the destination will become nothing as well,  
effectively deleting it.

> One more question - how to add origin/HEAD remote branch to local
> repo? If I create a new public repo, then add it as a remote (origin)
> in my local repo and push all changes it works fine.

I'm not quite sure what you mean by that. HEAD points to the head of  
the current branch, and origin/HEAD points to origin/master.

> But if I want to
> create a remote branch using "git push origin origin:refs/heads/
> new_feature_name" I get "error: src refspec origin does not match
> any.". If I clone the public repo, I can see remote branch "origin/
> HEAD" listed and creating remote branches works fine.

That's because it's looking for a local branch named "origin", which  
doesn't exist. You can either create a new branch locally, and then  
push it to the remote ("git branch new_feature_name; git push origin  
new_feature_name"), or run "git push origin  
master:new_feature_name" (assuming you want your branch based on  
master; the refs/heads-stuff isn't necessary with the later versions  
of Git). IMO the former strategy is usually preferable.

g, Markus

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"GitHub" group.
To post to this group, send email to github@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/github?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to