[m-dev.] git submodules

[Paul Bone]

On Thu, Oct 23, 2014 at 04:46:04PM +1100, Ben Schmidt wrote:
> 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

>
> 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