Re: Pushing to GitHub doesn't push all branches

Michael J Gruber wrote:

quoted

is only used for syncing svn -> our server -> github, I had to add a new 
commit which represents the svn-ignore meta data to a .gitignore file. I 
noticed I had to manually to a 'git checkout master' & 'git merge 
remotes/trunk' to pull in new updates. I thin pushed that to github.

You didn't tell us *that* before... Exactly this is why I asked whether
you want to do own work on those branches or just push a git-svn mirror.

When we last spoke, I did not have a .gitignore file. :)
That is the only change I plan to make in that repository (on our server).

I have cloned that repository (on our server) to my local PC. The one on 
my PC is a true Git repository and that is the one I'll be making 
changes to and emailing patches back to the FPC mailing list.

the only change you will make to the original branches. It keeps you
from doing a simple fetch and forces you to set up merging.

OK, so seeing that I already done that and pushed it to GitHub, I now 
need to always do the following on our server git repository.

  $ git svn fetch
  $ git checkout master
  $ git merge origin/trunk
  $ git push github            <-- updates remotes/* to heads/*
  $ git push github master     <-- updates remote master branch


So 'git push github' as I have show above should do the trick for all 
refts/remotes/* branches. I gather that excludes the "master" branch, so 
I still need to push that one manually as well. Correct?

In the newer Git v1.6.x versions there is a new default setting that can 
be set for push.

   $ git config push.default <type>

If I set that to "matching", then I should be able to only need one 'git 
push github' command, and that should push remotes/* and the "master" 
branch. Correct?

In my local repository on my work PC (not the server), I normally set 
the push.default to "current" so I don't accidentally push something 
that has an incomplete feature.

Also, svn-metadata may change over time. Do you intend to keep
.gitignore up to date with those changes?

No, just the initial setup.

- Push the git-svn converted branches as is, using the suggested refspec
(or having it in config and doing "git push github"). "git svn fetch"
will have fetched all svn refs you need.

OK, I haven't added a .gitignore to the fixes_2_2 local branch, so that 
one is still exactly as it was in SubVersion. And my local "fixes_2_2" 
has not been pushed to Github yet. So I should be able to just delete 
the local "fixes_2_2" branch. The normal refspec will push changes to 
Github as it should. So if anybody clones the Github repository, they 
can manually create their local "fixes_2_2" from the 
refs/remotes/fixes_2_2 branch. Correct?


I think I'm starting to see a little white light in the end of the 
tunnel. :-)

- Set up local branches and do your merge thing. In this case you
probably also want to keep up with svn metadata changes (mind that

I think I will leave the local "master" branch (mapped to SubVersion 
Trunk) as-is. I'll then modify my cron script to do a manual merge after 
the 'git svn fetch'.

I'm not going to bother updating the .gitignore again. So from now 
onwards the merge should be a simple fast-forward merge I take it and 
should never get conflicts again.

consists of .gitignore (and possibly other things) only. "git show
svnhelper:.gitignore > .git/info/excludes" will set up each user. You
can also use a tag for that (i.e. instead of a branch).

Very clever indeed - pity I did not think of it before. I'll make a note 
of this and if I ever clone another SubVersion repository, I'll do it 
with a tag or separate branch.



Regards,
   - Graeme -

-- 
fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal
http://opensoft.homeip.net/fpgui/