Re: A Proposal to Move to Git

Joseph S. Myers
2013-08-30T23:37:05Z

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