This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 1-800-GIT-HELP question


On Wed, 15 Jan 2020 at 10:14, Gaius Mulley <gaius.southwales@gmail.com> wrote:
>
>
> Hello,
>
> Firstly many thanks to all who have worked on the git migration and also
> for the offer of help :-)
>
> I'm seeking a little advice on an efficient way to combine the gm2 git
> repro with the gcc git repro.  When gcc was using subversion I had a
> script which untared the gm2 git over the subversion, applied local
> patches to the gcc tree and then it was ready for use.  I could git diff
> in the gm2 tree and svn diff in the gcc tree - etc.
>
> I wonder if a similar model can be achieved now gcc uses git?
>
> In essence the gm2 front end adds three subtrees to gcc
>
>     libgm2
>
>     gcc/m2
>
>     gcc/testsuite/gm2
>
> currently these are all in one repro
> gm2/gcc-versionno/{libgm2,gcc/m2,gcc/testsuite/gm2}.
>
> http://git.savannah.gnu.org/cgit/gm2.git/tree
>
> I'm a little cautious of choosing an initial working model without
> knowing the implications.  There seem to be many possible solutions
> (subtree, submodule) to name but two.

Personally I hate submodules, and I've never used subtree. If you need
to make modifications to files in GCC (rather than just adding
completely new dirs) then I don't think submodules would work at all,
I don't know about subtrees.

Is there a reason you can't just make it a branch of the GCC repo?

It would mean you need to merge from upstream GCC into your repo,
rather than just dropping your repo into/onto a GCC clone, but to me
it seems the more natural solution. The modifications to the files in
the GCC tree would also be in your branch (and properly tracked in
git), and so not need to be done manually after untarring gm2 into the
GCC tree.

It would mean your gm2 repo would contain the full GCC history, but
you said disk space isn't a concern. A checkout would need to check
out the full GCC tree as well, but presumably you need some way to
obtain that anyway if you're going to unpack/checkout/whatever the gm2
repo inside the GCC tree.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]