Re: A Proposal to Move to Git

[Hans-Peter Nilsson <hp at bitrange dot com>]

First and foremost, thanks for setting this in motion.

On Tue, 20 Aug 2013, Tom Tromey wrote:
> The basics of the plan are as outlined by Joseph Myers:
>
>     http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html
>
> For the purposes of this discussion I think you can focus on 6.b -- a
> shared gdb+binutils repository.
>
> The reason for a shared repository is simply that binutils and gdb
> share a substantial amount of code, mainly BFD, but other things as
> well.
>
> This gives the change minimal impact.  It is not zero impact, but:
>
> 1. It is superior for all of us to build the whole tree, to avoid
>    those (rare) occasions where BFD changes break other parts of the
>    build;

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.

The work-flow changes for those of us that *want* to still build
with separate trees (like, with auto-testers) should be written
down and supported, not just implied and left on our own.  I see
changes to the src-release scripts, so let's make that the
number one supported way of generating a separate tree: through
intermediate release-like tar-balls.  (No, not git sparse
checkouts.  Too many local steps that *will change as projects
add files*, and also needing something like git-1.7.10 to be
bug-free.)  But, lots of modules are unnamed in src-release, for
example the "sim" module.  Let's add those in CVSROOT/modules
that are missing from src-release but are still maintained in
the src tree (e.g. excluding dejagnu) as part of a migrated
project.  I see a couple of strange ones in the src-release
script that are not in CVSROOT/modules (like separate gas and
gas+binutils - without ld or gprof), so a pristine-ness-argument
can't be used as a counter-argument, please, thank you. :)

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.
That's a bit more than inconvenient.  Thus, there should be a
migration path offered as part of this effort and it's not
someone elses issue.  I guess someone will dislike the following
suggestion, but how about separate per-directory repos, using
git submodule, with steps explaining how to add them to your
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!

To summarize the actions I want:
- Git migrations and work-flow offered for remaining projects
(like newlib and cgen).
- (related:) Do not set in stone this git repo as "binutils+gdb"
in any documentation changes and names.
- Add remaining "partial checkout" methods as mentioned in
modules to src-release, for related migrating projects (well, at
least "sim").  Mention this as a (the only?) supported way to
generate the project-specific tree.

I'll add them to PR14768 and hope to make the src-release
changes unless beaten to it.

> I'd like to do the final switch around mid-September.  Not sooner,
> because I am going to be away for a little while near the end of
> August, and I want to be available to fix problems.

Very much appreciated.

brgds, H-P