public inbox for gsl-discuss@sourceware.org
 help / color / mirror / Atom feed
* Used git-bzr-ng to import bzr trunk into git master on Savannah
@ 2013-10-28 22:03 Rhys Ulerich
  2013-10-28 22:27 ` Patrick Alken
  0 siblings, 1 reply; 5+ messages in thread
From: Rhys Ulerich @ 2013-10-28 22:03 UTC (permalink / raw)
  To: gsl-discuss

Hi all,

Per the git-migration discussion we've been having intermittently...

After Patrick got the Savannah admins to bring up git for the GSL
project, I used git-bzr-ng [1] to import bzr trunk [2] into git master
[3].  If you browse our source tree for git [4], you'll see an
'oldmaster' branch and a 'master' branch in the upper right hand side
of the screen.  'master' is the default, it seems.  You can convince
yourself that oldmaster is indeed old [5] and master is indeed new
[6].

If someone will second the idea after having reviewed these things, I
will delete the 'oldmaster' branch.

Two things likely remain for the migration to be complete:
  1) A polite discussion on how we want to name branches.  Is 'master'
always the latest stable release with 'develop' being the work in
progress?  Should be adopt something like git-flow [7]?  What do we do
for having a 1.x support 'master' alongside a 2.x 'master'?
  2) Asking the Savannah admins to turn off bzr.

- Rhys

[1] https://github.com/termie/git-bzr-ng
[2] bzr+ssh://rhysu@bzr.savannah.gnu.org/gsl/trunk/
[3] rhysu@git.sv.gnu.org:/srv/git/gsl.git
[4] http://git.savannah.gnu.org/cgit/gsl.git
[5] http://git.savannah.gnu.org/cgit/gsl.git/log/?h=oldmaster
[6] http://git.savannah.gnu.org/cgit/gsl.git/log/?h=master
[7] http://nvie.com/posts/a-successful-git-branching-model/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Used git-bzr-ng to import bzr trunk into git master on Savannah
  2013-10-28 22:03 Used git-bzr-ng to import bzr trunk into git master on Savannah Rhys Ulerich
@ 2013-10-28 22:27 ` Patrick Alken
  2013-10-29  2:33   ` Rhys Ulerich
  0 siblings, 1 reply; 5+ messages in thread
From: Patrick Alken @ 2013-10-28 22:27 UTC (permalink / raw)
  To: gsl-discuss

Looks good after a quick glance. Just a few notes:

1. Unfortunately it looks like the tags weren't preserved past 1.14 (ie: 
release-1-15 and release-1-16 don't appear to be tagged in the git. This 
isn't terrible since we can always go back to the bzr for them if 
needed. Maybe bzr tags things in a way which isn't compatible with git.

2. We can turn off bzr whenever we want (its in the Main -> Select 
Features menu on savannah) - the savannah people renamed the old git to 
'oldmaster' for us, that we couldn't do on our own.

3. Still not sure about the 2.x issue. Another option is to continue 
using the bzr for the 1.x version and use the git to get started on 2.x 
features. Don't know if this would just make things more complicated.

Patrick

On 10/28/2013 04:02 PM, Rhys Ulerich wrote:
> Hi all,
>
> Per the git-migration discussion we've been having intermittently...
>
> After Patrick got the Savannah admins to bring up git for the GSL
> project, I used git-bzr-ng [1] to import bzr trunk [2] into git master
> [3].  If you browse our source tree for git [4], you'll see an
> 'oldmaster' branch and a 'master' branch in the upper right hand side
> of the screen.  'master' is the default, it seems.  You can convince
> yourself that oldmaster is indeed old [5] and master is indeed new
> [6].
>
> If someone will second the idea after having reviewed these things, I
> will delete the 'oldmaster' branch.
>
> Two things likely remain for the migration to be complete:
>    1) A polite discussion on how we want to name branches.  Is 'master'
> always the latest stable release with 'develop' being the work in
> progress?  Should be adopt something like git-flow [7]?  What do we do
> for having a 1.x support 'master' alongside a 2.x 'master'?
>    2) Asking the Savannah admins to turn off bzr.
>
> - Rhys
>
> [1] https://github.com/termie/git-bzr-ng
> [2] bzr+ssh://rhysu@bzr.savannah.gnu.org/gsl/trunk/
> [3] rhysu@git.sv.gnu.org:/srv/git/gsl.git
> [4] http://git.savannah.gnu.org/cgit/gsl.git
> [5] http://git.savannah.gnu.org/cgit/gsl.git/log/?h=oldmaster
> [6] http://git.savannah.gnu.org/cgit/gsl.git/log/?h=master
> [7] http://nvie.com/posts/a-successful-git-branching-model/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Used git-bzr-ng to import bzr trunk into git master on Savannah
  2013-10-28 22:27 ` Patrick Alken
@ 2013-10-29  2:33   ` Rhys Ulerich
  2013-10-30 21:57     ` Rhys Ulerich
  0 siblings, 1 reply; 5+ messages in thread
From: Rhys Ulerich @ 2013-10-29  2:33 UTC (permalink / raw)
  To: Patrick Alken; +Cc: gsl-discuss

> Looks good after a quick glance.

I'll take that as a yay vote.  After some digging, it seems I can't
make the HEAD symbolic reference point to master instead of oldmaster
without some help.
Patrick, would you please ask the Savannah folks about this?  I
suspect them running
    git symbolic-ref HEAD
would show
    refs/heads/oldmaster
whereas we want that to now say
    refs/heads/master
which (I think) requires issuing
    git symbolic-ref -m "Making updated master the default HEAD" HEAD
refs/heads/master
assuming ten minutes of Googling is enough background reading.

Once that's confirmed as done, I'll remove the existing oldmaster branch.

> 1. Unfortunately it looks like the tags weren't preserved past 1.14 (ie:
> release-1-15 and release-1-16 don't appear to be tagged in the git.

I believe I have this fixed.  Please confirm that
    git clone git://git.savannah.gnu.org/gsl.git
    cd gsl
    git tag -l
shows tags for release-1-15 and release-1-16.  Also
http://git.savannah.gnu.org/cgit/gsl.git/refs/?h=master is now showing
these entries.

> 2. We can turn off bzr whenever we want (its in the Main -> Select Features
> menu on savannah) - the savannah people renamed the old git to 'oldmaster'
> for us, that we couldn't do on our own.

I think only admins get that option in the Savannah UI.

> 3. Still not sure about the 2.x issue. Another option is to continue using
> the bzr for the 1.x version and use the git to get started on 2.x features.
> Don't know if this would just make things more complicated.

I'd rather not use two separate VCSes if we can avoid it.  Maybe we
can have a develop-1 for 1.x, master for stable 1.x, and a develop-2
for 2.x.  That would let folk play with 2.x so that we can revisit
this decision in the context of tangible code changes.

For now, there's enough 1.17-ish things to keep me busy in my
freetime.  In particular, I'd like to get Konrad's hermite polynomials
up in a branch so they can be reviewed before being merged.

- Rhys

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Used git-bzr-ng to import bzr trunk into git master on Savannah
  2013-10-29  2:33   ` Rhys Ulerich
@ 2013-10-30 21:57     ` Rhys Ulerich
  2013-10-30 22:16       ` Brian Gladman
  0 siblings, 1 reply; 5+ messages in thread
From: Rhys Ulerich @ 2013-10-30 21:57 UTC (permalink / raw)
  To: gsl-discuss

Just an update, bzr is turned off in the Savannah.

> I'd rather not use two separate VCSes if we can avoid it.  Maybe we
> can have a develop-1 for 1.x, master for stable 1.x, and a develop-2
> for 2.x.  That would let folk play with 2.x so that we can revisit
> this decision in the context of tangible code changes.

Along those lines, up on Savannah git I've got three branches in place:
  develop-1: Trunk for GSL 1.x releases
  develop-2: Trunk for GSL 2.x releases
  master:  Latest stable release, default branch on clone once
'oldmaster' is gone.

I'm thinking we treat develop-1 like we've been treating bzr and
develop-2 is the wild west for 2.x development.  Bug fixes will need
to go in both places.

Thoughts?

- Rhys

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Used git-bzr-ng to import bzr trunk into git master on Savannah
  2013-10-30 21:57     ` Rhys Ulerich
@ 2013-10-30 22:16       ` Brian Gladman
  0 siblings, 0 replies; 5+ messages in thread
From: Brian Gladman @ 2013-10-30 22:16 UTC (permalink / raw)
  To: Rhys Ulerich, gsl-discuss

On 30/10/2013 21:56, Rhys Ulerich wrote:
> Just an update, bzr is turned off in the Savannah.
> 
>> I'd rather not use two separate VCSes if we can avoid it.  Maybe we
>> can have a develop-1 for 1.x, master for stable 1.x, and a develop-2
>> for 2.x.  That would let folk play with 2.x so that we can revisit
>> this decision in the context of tangible code changes.
> 
> Along those lines, up on Savannah git I've got three branches in place:
>   develop-1: Trunk for GSL 1.x releases
>   develop-2: Trunk for GSL 2.x releases
>   master:  Latest stable release, default branch on clone once
> 'oldmaster' is gone.
> 
> I'm thinking we treat develop-1 like we've been treating bzr and
> develop-2 is the wild west for 2.x development.  Bug fixes will need
> to go in both places.
> 
> Thoughts?

Great work Rhys, its great to be able to use GIT for GSL development - I
much appreciate your efforts on this.

The arrangement you suggest should work well.  I haven't tried a commit
yet but this has worked with other GIT repos so I would not expect to
have any problems with this.

   Brian

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2013-10-30 22:16 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-10-28 22:03 Used git-bzr-ng to import bzr trunk into git master on Savannah Rhys Ulerich
2013-10-28 22:27 ` Patrick Alken
2013-10-29  2:33   ` Rhys Ulerich
2013-10-30 21:57     ` Rhys Ulerich
2013-10-30 22:16       ` Brian Gladman

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 read-only IMAP folder(s) and NNTP newsgroup(s).