From: Rhys Ulerich <rhys.ulerich@gmail.com>
To: Patrick Alken <patrick.alken@colorado.edu>
Cc: gsl-discuss@sourceware.org
Subject: Re: Used git-bzr-ng to import bzr trunk into git master on Savannah
Date: Tue, 29 Oct 2013 02:33:00 -0000 [thread overview]
Message-ID: <CAKDqugRqwSZNVKLZ+v0-wUDt332YG6k2fDsdUZnR=w3H7-gN_A@mail.gmail.com> (raw)
In-Reply-To: <526EE4B8.5010209@colorado.edu>
> 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
next prev parent reply other threads:[~2013-10-29 2:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-28 22:03 Rhys Ulerich
2013-10-28 22:27 ` Patrick Alken
2013-10-29 2:33 ` Rhys Ulerich [this message]
2013-10-30 21:57 ` Rhys Ulerich
2013-10-30 22:16 ` Brian Gladman
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='CAKDqugRqwSZNVKLZ+v0-wUDt332YG6k2fDsdUZnR=w3H7-gN_A@mail.gmail.com' \
--to=rhys.ulerich@gmail.com \
--cc=gsl-discuss@sourceware.org \
--cc=patrick.alken@colorado.edu \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).