All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.