git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Graeme Geldenhuys <graemeg@gmail.com>
To: git@vger.kernel.org
Subject: Re: Pushing to GitHub doesn't push all branches
Date: Mon, 13 Jul 2009 15:41:11 +0200	[thread overview]
Message-ID: <h3fdjg$770$1@ger.gmane.org> (raw)
In-Reply-To: <4A5B13FB.4040203@drmicha.warpmail.net>

Michael J Gruber wrote:
>> 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/

      reply	other threads:[~2009-07-13 13:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-10 13:24 Pushing to GitHub doesn't push all branches Graeme Geldenhuys
2009-07-10 14:45 ` Michael J Gruber
2009-07-10 14:58   ` Michael J Gruber
2009-07-10 15:07   ` Graeme Geldenhuys
2009-07-10 15:51     ` Michael J Gruber
2009-07-13  8:12       ` Graeme Geldenhuys
2009-07-13 11:01         ` Michael J Gruber
2009-07-13 13:41           ` Graeme Geldenhuys [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='h3fdjg$770$1@ger.gmane.org' \
    --to=graemeg@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).