sourceware and git

sourceware and git

[Jeff Johnston]

There have been some requests to put newlib into git.  I was wondering if
the overseers have recently looked into putting sourceware into git.  

I am also wondering how a piece of sourceware can be put into git without disrupting it.  What steps were
needed to move binutils and gdb over?  Apparently, the gdb-cvs mailing list continues to work and I would
like to have the same occur for our newlib-cvs list.  Any insight to the process would be
appreciated including issues found.

-- Jeff J.

Re: sourceware and git

[Joseph S. Myers]

On Tue, 29 Jul 2014, Jeff Johnston wrote:

> There have been some requests to put newlib into git.  I was wondering if
> the overseers have recently looked into putting sourceware into git.  
> 
> I am also wondering how a piece of sourceware can be put into git 
> without disrupting it.  What steps were needed to move binutils and gdb 
> over?  Apparently, the gdb-cvs mailing list continues to work and I 
> would like to have the same occur for our newlib-cvs list.  Any insight 
> to the process would be appreciated including issues found.

The basic rule for moving pieces of src CVS is that you move just a 
logical project rather than a group of unrelated projects.  I.e., if you 
want to move newlib to git, just move newlib (the directories and toplevel 
files that are used in a newlib build) rather than the whole repository.  
Then src CVS can be made readonly as I don't think any of the other 
projects have any significant activity.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: sourceware and git

[Christopher Faylor]

On Tue, Jul 29, 2014 at 06:14:30PM +0000, Joseph S. Myers wrote:
>On Tue, 29 Jul 2014, Jeff Johnston wrote:
>
>> There have been some requests to put newlib into git.  I was wondering if
>> the overseers have recently looked into putting sourceware into git.  
>> 
>> I am also wondering how a piece of sourceware can be put into git 
>> without disrupting it.  What steps were needed to move binutils and gdb 
>> over?  Apparently, the gdb-cvs mailing list continues to work and I 
>> would like to have the same occur for our newlib-cvs list.  Any insight 
>> to the process would be appreciated including issues found.
>
>The basic rule for moving pieces of src CVS is that you move just a 
>logical project rather than a group of unrelated projects.  I.e., if you 
>want to move newlib to git, just move newlib (the directories and toplevel 
>files that are used in a newlib build) rather than the whole repository.  
>Then src CVS can be made readonly as I don't think any of the other 
>projects have any significant activity.

I've been trying to convince Jeff and Corinna that the top-level stuff
isn't really needed for newlib.

I already have cygwin available as a self-contained git module which
doesn't use the top-level configury but which can still be dropped into
the standard tree along with gdb, gcc, binutils, and newlib.  But, you
can also just check cygwin out via, e.g.,
git clone ssh:sourceware.org/cygwin.git /usr/src/cygwin
and start building from that source directory, as long as you point it
to a version of newlib.  I was thinking that newlib could do the same.

Since cygwin needs newlib, I think that this means that cygwin could
import newlib as a submodule if it needed it.  The other proposal is to
keep newlib and cygwin in one git project.  That more or less keeps the
status quo for newlib and cygwin but it means that people who use newlib
without cygwin will have extra Windows-specific code that they don't
care about.  And, I think it would be nice to use the power of git to
allow a logical separation between the two projects.

Re: sourceware and git

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2842 bytes --]

On Jul 29 21:13, Christopher Faylor wrote:
> On Tue, Jul 29, 2014 at 06:14:30PM +0000, Joseph S. Myers wrote:
> >On Tue, 29 Jul 2014, Jeff Johnston wrote:
> >
> >> There have been some requests to put newlib into git.  I was wondering if
> >> the overseers have recently looked into putting sourceware into git.  
> >> 
> >> I am also wondering how a piece of sourceware can be put into git 
> >> without disrupting it.  What steps were needed to move binutils and gdb 
> >> over?  Apparently, the gdb-cvs mailing list continues to work and I 
> >> would like to have the same occur for our newlib-cvs list.  Any insight 
> >> to the process would be appreciated including issues found.
> >
> >The basic rule for moving pieces of src CVS is that you move just a 
> >logical project rather than a group of unrelated projects.  I.e., if you 
> >want to move newlib to git, just move newlib (the directories and toplevel 
> >files that are used in a newlib build) rather than the whole repository.  
> >Then src CVS can be made readonly as I don't think any of the other 
> >projects have any significant activity.
> 
> I've been trying to convince Jeff and Corinna that the top-level stuff
> isn't really needed for newlib.
> 
> I already have cygwin available as a self-contained git module which
> doesn't use the top-level configury but which can still be dropped into
> the standard tree along with gdb, gcc, binutils, and newlib.  But, you
> can also just check cygwin out via, e.g.,
> git clone ssh:sourceware.org/cygwin.git /usr/src/cygwin
> and start building from that source directory, as long as you point it
> to a version of newlib.  I was thinking that newlib could do the same.
> 
> Since cygwin needs newlib, I think that this means that cygwin could
> import newlib as a submodule if it needed it.  The other proposal is to
> keep newlib and cygwin in one git project.  That more or less keeps the
> status quo for newlib and cygwin but it means that people who use newlib
> without cygwin will have extra Windows-specific code that they don't
> care about.

And vice versa, since libgloss is part of the newlib module, but not part
of Cygwin.

> And, I think it would be nice to use the power of git to
> allow a logical separation between the two projects.

I don't really care for the toplevel stuff, but what I would like to see
is that both projects, newlib as well as Cygwin, can be checked out,
updated, branched, tagged, etc, in a single operation, just as before.
So

  git clone http://sourceware.org/cygwin.git

should check out cygwin + newlib (as submodule?) and

  git clone http://sourceware.org/newlib.git

should check out newlib + libgloss (as submodule?).

Is that possible with git?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: sourceware and git

[Christopher Faylor]

On Wed, Jul 30, 2014 at 09:47:58AM +0200, Corinna Vinschen wrote:
>On Jul 29 21:13, Christopher Faylor wrote:
>> And, I think it would be nice to use the power of git to
>> allow a logical separation between the two projects.
>
>I don't really care for the toplevel stuff, but what I would like to see
>is that both projects, newlib as well as Cygwin, can be checked out,
>updated, branched, tagged, etc, in a single operation, just as before.
>So
>
>  git clone http://sourceware.org/cygwin.git
>
>should check out cygwin + newlib (as submodule?) and
>
>  git clone http://sourceware.org/newlib.git
>
>should check out newlib + libgloss (as submodule?).
>
>Is that possible with git?

If git can't automatically check out newlib as a submodule then we could
just include a 'tag' script somewhere in cygwin.  You're going to have
to learn a new command to tag things anyway so if it's "git tag" or
"./tag-cygwin-newlib" it shouldn't be that big a deal.

cgf

Re: sourceware and git

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 1949 bytes --]

On Jul 30 11:18, Christopher Faylor wrote:
> On Wed, Jul 30, 2014 at 09:47:58AM +0200, Corinna Vinschen wrote:
> >On Jul 29 21:13, Christopher Faylor wrote:
> >> And, I think it would be nice to use the power of git to
> >> allow a logical separation between the two projects.
> >
> >I don't really care for the toplevel stuff, but what I would like to see
> >is that both projects, newlib as well as Cygwin, can be checked out,
> >updated, branched, tagged, etc, in a single operation, just as before.
> >So
> >
> >  git clone http://sourceware.org/cygwin.git
> >
> >should check out cygwin + newlib (as submodule?) and
> >
> >  git clone http://sourceware.org/newlib.git
> >
> >should check out newlib + libgloss (as submodule?).
> >
> >Is that possible with git?
> 
> If git can't automatically check out newlib as a submodule then we could
> just include a 'tag' script somewhere in cygwin.  You're going to have
> to learn a new command to tag things anyway so if it's "git tag" or
> "./tag-cygwin-newlib" it shouldn't be that big a deal.

But it's not just that, it's about all bulk commands.  You don't really
want to create scripts for all these git actions just because git
doesn't handle them, do you?  What advantage has git if it doesn't allow
to define stuff which was naturally under CVS.  Moving to git is supposed
to be progress and not a step back in the usage pattern.

What about libgloss?  If libgloss is an inherent part of the newlib git
repo, a checkout of a newlib submodule would also pull in libgloss.  Do
we want to keep it or do we want to remove it post-clone?  I'm concerned
about creating the source packages as part of the distro packaging.  A
source checkout of Cygwin should checkout all sources and not only via
some configure statement or by running another post-clone script.

Am I really asking too much?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: sourceware and git

[Joseph S. Myers]

On Wed, 30 Jul 2014, Corinna Vinschen wrote:

> But it's not just that, it's about all bulk commands.  You don't really
> want to create scripts for all these git actions just because git
> doesn't handle them, do you?  What advantage has git if it doesn't allow
> to define stuff which was naturally under CVS.  Moving to git is supposed
> to be progress and not a step back in the usage pattern.

Indeed.  It's best if all operations work in their natural, native git 
ways, which may mean avoiding submodules.

> What about libgloss?  If libgloss is an inherent part of the newlib git
> repo, a checkout of a newlib submodule would also pull in libgloss.  Do
> we want to keep it or do we want to remove it post-clone?  I'm concerned
> about creating the source packages as part of the distro packaging.  A
> source checkout of Cygwin should checkout all sources and not only via
> some configure statement or by running another post-clone script.

I'd say have all of libgloss, newlib, Cygwin in one repository - the 
irrelevant parts can always be removed on release branches of each 
component if you want, or people can simply use --disable-<dir> options as 
needed like they do for binutils-gdb checkouts.  A practical mostly 
self-contained repository for those three (followed by making src CVS 
readonly) seems better and easier to achieve and use than some sort of 
theoretical purity.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: sourceware and git

[Hans-Peter Nilsson]

On Wed, 30 Jul 2014, Christopher Faylor wrote:
> On Wed, Jul 30, 2014 at 09:47:58AM +0200, Corinna Vinschen wrote:
> >  git clone http://sourceware.org/cygwin.git
> >
> >should check out cygwin + newlib (as submodule?) and
> >
> >  git clone http://sourceware.org/newlib.git
> >
> >should check out newlib + libgloss (as submodule?).
> >
> >Is that possible with git?

(A subsequent command is needed with git submodules, which I see
have no supporters here, so I'll refrain from saying "git
submodule update --init --recursive" ...oops. :)

> If git can't automatically check out newlib as a submodule then we could
> just include a 'tag' script somewhere in cygwin.  You're going to have
> to learn a new command to tag things anyway so if it's "git tag" or
> "./tag-cygwin-newlib" it shouldn't be that big a deal.

It seems natural to amend the top-level src-release makefile
with targets newlib.tar.bz2 and cygwin.tar.bz2, similar to sim,
binutils and gdb that were at one time CVS modules (with the
obvious caveat of no-longer-shared toplevel files).

You'd have the git-checkout containing everything, but at least
you can create official-release-type and snapshot tar-balls with
the expected contents.

brgds, H-P

Re: sourceware and git

[Joseph S. Myers]

On Tue, 29 Jul 2014, Christopher Faylor wrote:

> I've been trying to convince Jeff and Corinna that the top-level stuff
> isn't really needed for newlib.

It's needed as the way that newlib gets configured for the right set of 
multilibs, to be installed in the right directories!

> Since cygwin needs newlib, I think that this means that cygwin could
> import newlib as a submodule if it needed it.  The other proposal is to
> keep newlib and cygwin in one git project.  That more or less keeps the
> status quo for newlib and cygwin but it means that people who use newlib
> without cygwin will have extra Windows-specific code that they don't
> care about.  And, I think it would be nice to use the power of git to
> allow a logical separation between the two projects.

I think having them in one git project (that includes libgloss and the 
relevant toplevel) would be fine.  I'm generally dubious of things such as 
submodules; I think basic requirements include: checking out with git:// 
gets a git:// checkout of everything; checking out with git+ssh:// gets a 
git+ssh:// checkout of everything; pulling automatically pulls changes to 
everything; branching, tagging etc. (and pushing those branches or tags) 
automatically branches, tags etc. everything.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: sourceware and git

[Christopher Faylor]

On Wed, Jul 30, 2014 at 05:02:47PM +0000, Joseph S. Myers wrote:
>I think having them in one git project (that includes libgloss and the 
>relevant toplevel) would be fine.  I'm generally dubious of things such as 
>submodules;

Your dubiousity doesn't have any bearing if it isn't backed up by facts.
If submodules can't be made to work transparently then that is an
argument for why they might not be used.  A fear of submodules doesn't
translate into rejecting the concept.

Re: sourceware and git

[Joseph S. Myers]

On Wed, 30 Jul 2014, Christopher Faylor wrote:

> On Wed, Jul 30, 2014 at 05:02:47PM +0000, Joseph S. Myers wrote:
> >I think having them in one git project (that includes libgloss and the 
> >relevant toplevel) would be fine.  I'm generally dubious of things such as 
> >submodules;
> 
> Your dubiousity doesn't have any bearing if it isn't backed up by facts.

It's backed up by the list of requirements I gave for git to work smoothly 
in the presence of submodules as if there were a single repository, none 
of which (according to the git-submodule manpage) git submodules meet.

We have many years' experience of the src repository being problematic 
because of the use of a special feature of CVS (modules files for partial 
checkouts of a directory in the repository) that doesn't work well with 
other features of CVS (cvs update -d; the interaction of modules file 
changes with tagging and branching).  That also provides a basis for 
caution about such features in other version control systems, and for 
preferring an ordinary git repository whose clones work with ordinary git 
commands just like those commands work with clones of any other random git 
repository.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: sourceware and git

[Christopher Faylor]

On Wed, Jul 30, 2014 at 08:57:20PM +0000, Joseph S. Myers wrote:
>On Wed, 30 Jul 2014, Christopher Faylor wrote:
>
>> On Wed, Jul 30, 2014 at 05:02:47PM +0000, Joseph S. Myers wrote:
>> >I think having them in one git project (that includes libgloss and the 
>> >relevant toplevel) would be fine.  I'm generally dubious of things such as 
>> >submodules;
>> 
>> Your dubiousity doesn't have any bearing if it isn't backed up by facts.
>
>It's backed up by the list of requirements I gave for git to work smoothly 
>in the presence of submodules as if there were a single repository, none 
>of which (according to the git-submodule manpage) git submodules meet.

You mentioned that you were dubious of "things such as submodules" which
sounds a lot like an unreasoning prejudice rather than an informed
opinion.  And, you specified a list of what you think is needed but
didn't back it up with "...and here's why submodules won't work".

From what I've read on the internet it is possible to make a lot (if not
all) of the submodule stuff happen automatically.  But, even if it
wasn't we're talking about Cygwin here which I'm willing to bet is not
something that you even have occasion to build.

>We have many years' experience of the src repository being problematic
>because of the use of a special feature of CVS (modules files for
>partial checkouts of a directory in the repository) that doesn't work
>well with other features of CVS (cvs update -d; the interaction of
>modules file changes with tagging and branching).  That also provides a
>basis for caution about such features in other version control systems,
>and for preferring an ordinary git repository whose clones work with
>ordinary git commands just like those commands work with clones of any
>other random git repository.

Hopefully you aren't trying to one-up me on "devo" experience.

You're overplaying the problems with CVS modules but since git is
obviously intended to be several orders of magnitude improvement over
CVS (which is the point of converting) there is no reason to
automaticaly avoid something called a "module" in git because you didn't
like how CVS implemented them.

CVS also had pecularities with branching and tagging but we're still
talking about branching and tagging in git.

As far as tagging is concerned, I don't see any reason why newlib
should be tagged when cygwin is tagged.  Cygwin shouldn't care about
newlib tags.

Re: sourceware and git

[Joseph S. Myers]

On Wed, 30 Jul 2014, Christopher Faylor wrote:

> >From what I've read on the internet it is possible to make a lot (if not
> all) of the submodule stuff happen automatically.  But, even if it
> wasn't we're talking about Cygwin here which I'm willing to bet is not
> something that you even have occasion to build.

I'm concerned with newlib checkouts working smoothly (and consider newlib 
to include libgloss and the associated toplevel build support, toplevel 
config/ directory which has settings that affect newlib, etc.).

I'm not concerned with what Cygwin does.  If you have an approach that 
treats Cygwin as a completely separate project, so that a git clone of 
newlib gets newlib / libgloss / toplevel (all the files and directories 
that go in newlib release tarballs, basically) but not Cygwin, and normal 
git operations work normally in that clone, I'm not concerned with what 
sequence of commands may be needed to generate and use a Cygwin checkout 
if the sequence in question works for the Cygwin community.  In principle 
I believe independent projects should be free to make their independent 
choices as far as possible - including choosing completely different 
version control systems if you want.

So, I think separating newlib and libgloss, or newlib and toplevel, into 
separate repositories, and then trying to stitch them together, would be a 
bad idea - libgloss is part of newlib and the toplevel build is 
essentially tied to the subdirectories.  But separating Cygwin from 
(newlib + libgloss + relevant toplevel) is a matter of what works for 
Cygwin people.

> CVS (which is the point of converting) there is no reason to
> automaticaly avoid something called a "module" in git because you didn't
> like how CVS implemented them.

It's nothing to do with the name - it's a common issue with both features 
(that if you use them, various operations no longer work as smoothly as if 
you don't).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: sourceware and git

[Yaakov Selkowitz]

On Wed, 2014-07-30 at 17:33 -0400, Christopher Faylor wrote:
> As far as tagging is concerned, I don't see any reason why newlib
> should be tagged when cygwin is tagged.  Cygwin shouldn't care about
> newlib tags.

What I don't understand yet is why our situation is different than
binutils-gdb, the two of which also have separate release schedules and
yet share enough code that they chose to use a single repository.  Given
that, IIUC:

* newlib and libgloss are developed in tandem;

* newlib and libgloss are meant to be built together;

* newlib and libgloss require the top-level configury in order to build;

then wouldn't the most straightforward (and reliable) method for
newlib/libgloss be to have a single git repo matching the layout of cvs
co newlib?

As for cygwin's usage of newlib, since pulling in newlib would end up
including libgloss and the top level configury, the only difference I
see between a joint newlib/libgloss/cygwin repo and a separate cygwin
repo would be that the former would not require any changes to the
cygwin build system, where the latter would.

Either way, yes, a cygwin checkout (or source tarball) would be somewhat
larger then it is now by virtue of the addition of libgloss to the
checkout.  (The top-level configury already skips building libgloss for
cygwin even when present.)  If the newlib folks don't mind the same
(although winsup is smaller than libgloss, so it's not quite an equal
tradeoff :-) ), then following the lead of binutils-gdb and using a
single repository makes a lot of sense to me.


Yaakov

Re: sourceware and git

[Christopher Faylor]

On Wed, Jul 30, 2014 at 06:41:25PM -0500, Yaakov Selkowitz wrote:
>On Wed, 2014-07-30 at 17:33 -0400, Christopher Faylor wrote:
>> As far as tagging is concerned, I don't see any reason why newlib
>> should be tagged when cygwin is tagged.  Cygwin shouldn't care about
>> newlib tags.
>
>What I don't understand yet is why our situation is different than
>binutils-gdb, the two of which also have separate release schedules and
>yet share enough code that they chose to use a single repository.  Given
>that, IIUC:

I don't care about newlib/libgloss.  The need for libgloss is enough for
me to withdraw that newlib should be standalone.

The difference here is that I'm involved with cygwin.  I didn't care
about binutils+gdb so I didn't weigh in.  I'm weighing in now.

>* newlib and libgloss are developed in tandem;
>
>* newlib and libgloss are meant to be built together;
>
>* newlib and libgloss require the top-level configury in order to build;
>
>then wouldn't the most straightforward (and reliable) method for
>newlib/libgloss be to have a single git repo matching the layout of cvs
>co newlib?
>
>As for cygwin's usage of newlib, since pulling in newlib would end up
>including libgloss and the top level configury, the only difference I
>see between a joint newlib/libgloss/cygwin repo and a separate cygwin
>repo would be that the former would not require any changes to the
>cygwin build system, where the latter would.

I have already made the changes for cygwin.  Is this not sinking in
somehow?  I was trying to make cygwin like most other GNU projects out
there, unencumbered by decades of top-level build accretion, relying on
only one other library, similar to the way other projects do it.

Anyway, nevermind.  I see that I'm in the minority.  My changes and git
repository are withdrawn.  Do what you like.

cgf

Re: sourceware and git

[Corinna Vinschen]

[-- Attachment #1: Type: text/plain, Size: 2414 bytes --]

On Jul 30 22:22, Christopher Faylor wrote:
> On Wed, Jul 30, 2014 at 06:41:25PM -0500, Yaakov Selkowitz wrote:
> >On Wed, 2014-07-30 at 17:33 -0400, Christopher Faylor wrote:
> >> As far as tagging is concerned, I don't see any reason why newlib
> >> should be tagged when cygwin is tagged.  Cygwin shouldn't care about
> >> newlib tags.
> >
> >What I don't understand yet is why our situation is different than
> >binutils-gdb, the two of which also have separate release schedules and
> >yet share enough code that they chose to use a single repository.  Given
> >that, IIUC:
> 
> I don't care about newlib/libgloss.  The need for libgloss is enough for
> me to withdraw that newlib should be standalone.
> 
> The difference here is that I'm involved with cygwin.  I didn't care
> about binutils+gdb so I didn't weigh in.  I'm weighing in now.
> 
> >* newlib and libgloss are developed in tandem;
> >
> >* newlib and libgloss are meant to be built together;
> >
> >* newlib and libgloss require the top-level configury in order to build;
> >
> >then wouldn't the most straightforward (and reliable) method for
> >newlib/libgloss be to have a single git repo matching the layout of cvs
> >co newlib?
> >
> >As for cygwin's usage of newlib, since pulling in newlib would end up
> >including libgloss and the top level configury, the only difference I
> >see between a joint newlib/libgloss/cygwin repo and a separate cygwin
> >repo would be that the former would not require any changes to the
> >cygwin build system, where the latter would.
> 
> I have already made the changes for cygwin.  Is this not sinking in
> somehow?  I was trying to make cygwin like most other GNU projects out
> there, unencumbered by decades of top-level build accretion, relying on
> only one other library, similar to the way other projects do it.
> 
> Anyway, nevermind.  I see that I'm in the minority.  My changes and git
> repository are withdrawn.  Do what you like.

Hmm, that wasn't exactly what I was looking for.  I was just trying to
make sure that the git repo for Cygwin contains all of Cygwin, and that
includes newlib.  It's not just an external library, it's an inherent
part of Cygwin.  You can't build Cygwin without newlib and you can't
build a standalone newlib for Cygwin without the Cygwin sources.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: sourceware and git

[Frank Ch. Eigler]

Hi -

On Fri, Aug 01, 2014 at 01:05:18PM +0200, Corinna Vinschen wrote:

> [...]  I was just trying to make sure that the git repo for Cygwin
> contains all of Cygwin, and that includes newlib.  It's not just an
> external library, it's an inherent part of Cygwin.

Well, not in the usual sense of "part of".

> You can't build Cygwin without newlib 

That sounds like any normal dependency.

> and you can't build a standalone newlib for Cygwin without the
> Cygwin sources.

That sounds like a possible packaging/bootstrapping detail, not an
"is-part-of" relationship.  (Consider glibc vs. linux-kernel, or gcc
vs. glibc, etc.)


Rather than focus on the building dependency aspects though, consider
focusing on actual project operation / community.  Are newlib/libgloss
is maintained/released by a different group of people on a different
schedule than cygwin?

- FChE

Re: sourceware and git

[Yaakov Selkowitz]

On Fri, 2014-08-01 at 18:54 -0400, Frank Ch. Eigler wrote:
> Rather than focus on the building dependency aspects though, consider
> focusing on actual project operation / community.  Are newlib/libgloss
> is maintained/released by a different group of people on a different
> schedule than cygwin?

There is some overlap (namely Corinna), but mostly we are separate
groups and the release schedule is definitely separate.  But that too we
have in common with binutils-gdb communities, yet the technical aspects
obviously brought them to decide upon a single joint repository.

I guess the question now is, are there any objections from the
newlib/libgloss folks in doing the same?


Yaakov

Re: sourceware and git

[Tom Tromey]

Jeff> What steps were needed to move binutils and gdb over?

The binutils-gdb move was very complicated, primarily because there were
multiple repositories to stitch together, but relatedly because the
original imports to sourceware were done inconsistently.

The steps I followed are documented in the README.md here (just scroll
down):

    https://github.com/tromey/gdb-git-migration

All the scripts are there.  If you want to reuse them, just fork the
project and hack them up to do what you like.

Jeff> Apparently, the gdb-cvs mailing list continues to work and I would
Jeff> like to have the same occur for our newlib-cvs list.

The mail hook stuff is already on sourceware but you can follow copies
in the "finalize-git-repo" script to see how it is configured.
"src-email" shows how this is done, though your setup may be simpler if
you just have a single commits list.

Tom