Re: A Proposal to Move to Git

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 30 Aug 2013, Hans-Peter Nilsson wrote:

> Sorry, but I have to react on that.  I waited a bit, but I
> really must say it: you say "all of us" like a the majority, but
> I doubt that there are more of "all of you" than "all of us"
> working on trees checked out as separate projects.  Also, how is
> that a change worth mentioning?  *Your* work-flow isn't changed,
> as you already check out gdb+binutils.  I can accept the
> inconvenience of the changed default thing that happens for "all
> of us" remaining, and having to adjust my work-flow somewhat,
> but I refuse to smile and call it good.  For example, we'll now
> each by default (when just going "make" after configure, not
> "make all-foo all-bar all-baz" for the bits in our project) be
> exposed to breakages in "the other" project, breakages unrelated
> to "our own" project.  Ok, now that I've got that out, over to
> some more constructive comments.

To build just one project, use --disable-<directory> options (this is 
already generically supported at toplevel).  It would be useful for there 
to be documentation listing sets of such options to use for building 
particular subsets of projects.

> At first I thought there was a huge inconvenience to projects
> left in the cold with CVS, but it it's less huge, it seems they
> will still be able to continue as they were - *except* they
> won't be able to update the shared files like configure.ac.

Rather, changing shared files now needs three repositories rather than two 
to change.  If we can get agreement on GCC as the master, this could be 
automated as it is for libiberty (check into GCC and let the automatic 
process merge to the others).  (Actually, my analysis suggests a master 
toplevel.git repository from which merges to all the others happen.  But 
that's not required and can always be added later.)

> local "src" tree?  Ok, now that you read and disliked that, how
> about the obvious alternative; offering to add them later to the
> binutils+gdb git?  Then I think it would be preferred to *not*
> name the git repo "the gdb+binutils repo", but (ehhh...) the src
> repo!

No, I think it should be binutils+gdb and other projects should not be 
added to it.  Most of the problems with the combined repository have been 
because it combines logically unrelated projects.  A key goal as I see it 
is that checkouts, updates, branching, tagging etc. work in the ordinary 
way for the version control system being used, without any further special 
steps or oddities - the existing use of CVS modules fails that ("cvs 
update -d" checks out things that aren't wanted in your partial checkouts) 
and so do things such as git submodules - which indicates avoiding such 
things in git arrangements.  Given how BFD is an integral part of both 
binutils and GDB, a binutils+gdb repository seems to be the smallest 
convenient unit.

> To summarize the actions I want:
> - Git migrations and work-flow offered for remaining projects
> (like newlib and cgen).

By design, it's for each project to choose to migrate or not, to its own 
repository, independently, including choosing whether git is the version 
control system they want at all.

As I noted in <http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html>, cgen 
doesn't appear to use the shared toplevel at all, so if it moves out of 
src, it would just be the cgen directory moving without a copy of anything 
at toplevel; with regard to binutils+gdb, it's just another build tool.

If all active projects move out, we really ought then to try to sort out 
the Unix groups on sourceware (replace the "src" group by putting the 
people writing to each project in a group for that project which controls 
access to just the relevant repository - so a binutils+gdb group, a newlib 
group, etc.).

-- 
Joseph S. Myers
joseph@codesourcery.com