git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Pushing to GitHub doesn't push all branches

From
Michael J Gruber <git@drmicha.warpmail.net>
Date
Jul 10, 2009, 15:51 UTC
Message-ID
<4A57639D.4020305@drmicha.warpmail.net>
In-Reply-To
<h37lh2$q3s$1@ger.gmane.org>
Graeme Geldenhuys venit, vidit, dixit 10.07.2009 17:07:
Show 44 quoted lines
> Michael J Gruber wrote:
>>
>> You really mirrored your repo: All your "lost" branches are remotes on
>> the github side as well. That has two consequences:
> 
> The two branches that are of most importance to me, is "trunk" and 
> "fixes_2_2" as found in the SubVersion repository.
> 
> refs/remotes/trunk
> refs/remotes/fixes_2_2
> 
> 
> So should I have only pushed the above mentioned branches, but as "true" 
> heads in GitHub. Geesh, I hope I am understanding what I am typing, 
> because I feel a bit lost now. :-)
> 
> Is there any way to clean up the mess available on GitGub? So that 'git 
> ls-remote ...' will only show the real remotes.... Or should there be no 
> remotes on GitHub?
> 
> Sorry, I'm fairly new to Git and it feels like I jumped into the deap 
> end here. ;-)
> 
>> (assuming there are only svn branches) into proper heads on github, i.e.
>> a refspec like '+refs/remotes/*:refs/*' for your pushes.
> 
> I'll read the man pages on what that refspec means...  If I manage to 
> only push 'trunk' which is master under git and 'fixes_2_2' which will 
> be some other name under git, how to I keep both those in sync with the 
> SubVersion repository.
> 
> At the moment I have a cronjob that executes the following every 30 minutes.
> ====================
> cd /mnt/samba/git/fpc.git/
> $GIT checkout master
> $GIT svn rebase
> $GIT gc --auto
> $GIT push origin master
> ====================
> 
> Does 'git svn rebase' get all branch or does it just update "master" 
> (Trunk from SubVersion)?
> 
> I apologise for all the questions...
Please don't! That's what we're here for ;)

A while ago I suggested that by default, no clone (whether git or git-svn) should have a master branch. I guess your example shows why. If you use that repo (/mnt/samba/git/fpc.git) only for converting from svn to git, not for doing local work, then you don't need any master branch. But git-svn will stubbornly recreate one.

Similarly (under the same assumption), you don't need to rebase at all. All you need is "git svn fetch", which populates the branches under remotes/.

You can safely delete the bogus remote branches on github using
git push origin :refs/remotes/trunk
etc., i.e.

git for-each-ref --shell --format="git push -f origin :%(refname)" refs/remotes/|while read line; do eval $line;done

(all on one line)
Then it's probably beneficial to do something like
git config remote.origin.push '+refs/remotes/*:refs/heads/*'

so that you have a nice default refspec for origin. [You may think about renaming origin to destination, though ;) ]

Cheers, Michael

Previous: Graeme GeldenhuysNext: Graeme Geldenhuys
Message 5 of 8 in “Pushing to GitHub doesn't push all branches”
  1. Graeme GeldenhuysJul 10, 2009
  2. Michael J GruberJul 10, 2009
  3. Michael J GruberJul 10, 2009
  4. Graeme GeldenhuysJul 10, 2009
  5. Michael J GruberJul 10, 2009
  6. Graeme GeldenhuysJul 13, 2009
  7. Michael J GruberJul 13, 2009
  8. Graeme GeldenhuysJul 13, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.