[m-dev.] git submodules

[Paul Bone]

Hi.

The Mercury programming langauge uses BDW GC. We've made a few changes to
the GC and so we build it in the Mercury tree, libatomic_ops also.

I'm about to upgrade Mercury to use BDWGC 7.4.2 (from 7.2) and this is an
opportunity to change the way we track the GC's changes as it's the first
upgrade since we started using git (from CVS).

I'm considering using git submodules to import the GC's sources into
Mercury's build tree:

mercury/
mercury/boehm_gc
mercury/boehm_gc/libatomic_ops

And if I import the gc's sources this way it would be convenient for the GC
to import libatomic_ops sources in a similar way. I don't know if this is
useful or desirable for anyone else but I thought I'd ask because it will
change what I do next.

I've submitted a pull request that adds libatomic_opts as a submodule.
After checking out the collector's sources you can issue "git submodule
update --init" to import libatomic_ops. Git will look for the
libatomic_opts repository at location relative to the "origin" repository of
../libatomic_opts.git (I think, I'm still learning how to use submodules.)

https://github.com/ivmai/bdwgc/pull/61

Thanks.

[Ben Schmidt]

It strikes me that if you want to modify the sources, a submodule is not
a good idea, and a good old-fashioned vendor branch is smarter. It's
more integrated with your main repository, and your changes to the
upstream sources can be automatically merged. With a submodule, you've
got an unnecessary layer of indirection: first you have to make a
repository that contains the upstream repository in a vendor branch,
plus your changes, and then you have to import that submodule into your
main project. Might as well just put the vendor branch in your main
project.

That said, I know little about Git. Full disclosure: I don't like it
(always sad to see good projects such as Mercury move to it;
fortunately, with a plugin, Mercurial can use Git repositories). Thus my
comments may be more appropriate to Mercurial subrepositories than Git
submodules (which are similar, but of course not the same).

Ben.

Post by Paul Bone
Hi.
The Mercury programming langauge uses BDW GC. We've made a few changes to
the GC and so we build it in the Mercury tree, libatomic_ops also.
I'm about to upgrade Mercury to use BDWGC 7.4.2 (from 7.2) and this is an
opportunity to change the way we track the GC's changes as it's the first
upgrade since we started using git (from CVS).
I'm considering using git submodules to import the GC's sources into
mercury/
mercury/boehm_gc
mercury/boehm_gc/libatomic_ops
And if I import the gc's sources this way it would be convenient for the GC
to import libatomic_ops sources in a similar way. I don't know if this is
useful or desirable for anyone else but I thought I'd ask because it will
change what I do next.
I've submitted a pull request that adds libatomic_opts as a submodule.
After checking out the collector's sources you can issue "git submodule
update --init" to import libatomic_ops. Git will look for the
libatomic_opts repository at location relative to the "origin" repository of
../libatomic_opts.git (I think, I'm still learning how to use submodules.)
https://github.com/ivmai/bdwgc/pull/61
Thanks.

[Paul Bone]

Post by Ben Schmidt
It strikes me that if you want to modify the sources, a submodule is not
a good idea, and a good old-fashioned vendor branch is smarter. It's
more integrated with your main repository, and your changes to the
upstream sources can be automatically merged. With a submodule, you've
got an unnecessary layer of indirection: first you have to make a
repository that contains the upstream repository in a vendor branch,
plus your changes, and then you have to import that submodule into your
main project. Might as well just put the vendor branch in your main
project.

Hi Ben,

I think I still owe you that coffee from 2006.

There's some discussion about this on the reviews list already. One of the
suggestions was to avoid adding Boehm GC's history to the Mercury project's
history. So I don't mind forking boehm and maintaining our patches there.
This may also help us get more of our changes into upstream. I don't mind
if Mercury's changes to the GC are in our repository or a seperate bdwgc
repository.

http://www.mercurylang.org/list-archives/reviews/2014-October/thread.html

Post by Ben Schmidt
That said, I know little about Git. Full disclosure: I don't like it
(always sad to see good projects such as Mercury move to it;
fortunately, with a plugin, Mercurial can use Git repositories). Thus my
comments may be more appropriate to Mercurial subrepositories than Git
submodules (which are similar, but of course not the same).

Heh, I don't like Mercurial, but it was a long time ago when I last tried
it. I'm aware of git's problems but I've come to accept them.

Cheers.

[Paul Bone]

Hi Paul,
I don't like the idea (at least at this moment) of libatomic_ops submodule (nor the idea of excluding the folder from gitignore) to be committed to upstream.
There are several ways of dealing with dependency tracking - each has pros and cons - let the client decide.

Okay, I can see how you loose flexability by doing that. This is
flexability that we (Mercury) have never had so I didn't notice until you
pointed it out.

In particular, subtree merge could be used instead of submodules.
But, if you still prefer submodules, you could put libatomic_ops directly to your project (making a link bdwgc/libatomic_ops -> libatomic_ops)

I think that's what we'll end up doing then. Yes we prefer submodules as
there's no need to import Boehm GC's history into the Mercury repository.

Thanks.

[Ben Schmidt]

It strikes me that if you want to modify the sources, a submodule is not
a good idea, and a good old-fashioned vendor branch is smarter. It's
more integrated with your main repository, and your changes to the
upstream sources can be automatically merged. With a submodule, you've
got an unnecessary layer of indirection: first you have to make a
repository that contains the upstream repository in a vendor branch,
plus your changes, and then you have to import that submodule into your
main project. Might as well just put the vendor branch in your main
project.

That said, I know little about Git. Full disclosure: I don't like it
(always sad to see good projects such as Mercury move to it;
fortunately, with a plugin, Mercurial can use Git repositories). Thus my
comments may be more appropriate to Mercurial subrepositories than Git
submodules (which are similar, but of course not the same).

Ben.

Post by Paul Bone
Hi.
The Mercury programming langauge uses BDW GC. We've made a few changes to
the GC and so we build it in the Mercury tree, libatomic_ops also.
I'm about to upgrade Mercury to use BDWGC 7.4.2 (from 7.2) and this is an
opportunity to change the way we track the GC's changes as it's the first
upgrade since we started using git (from CVS).
I'm considering using git submodules to import the GC's sources into
mercury/
mercury/boehm_gc
mercury/boehm_gc/libatomic_ops
And if I import the gc's sources this way it would be convenient for the GC
to import libatomic_ops sources in a similar way. I don't know if this is
useful or desirable for anyone else but I thought I'd ask because it will
change what I do next.
I've submitted a pull request that adds libatomic_opts as a submodule.
After checking out the collector's sources you can issue "git submodule
update --init" to import libatomic_ops. Git will look for the
libatomic_opts repository at location relative to the "origin" repository of
../libatomic_opts.git (I think, I'm still learning how to use submodules.)
https://github.com/ivmai/bdwgc/pull/61
Thanks.