On 17 Paź, 15:54, Markus Prinz <[EMAIL PROTECTED]> wrote:
> 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
Thanks for clearing things up
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"GitHub" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
