[m-rev.] Upgrading Boehm GC, the git way.

Paul Bone paul at bone.id.au
Tue Oct 21 14:10:31 AEDT 2014


On Tue, Oct 21, 2014 at 12:36:58PM +1100, Peter Wang wrote:
> On Mon, 20 Oct 2014 21:16:44 +1100, Paul Bone <paul at bone.id.au> wrote:
> > 
> > Offhand I don't know of an automated way, but we could manually squish these
> > together.  This may make git merges more difficult though as it removes a
> > common root (in history if not in file contents) when doing a 3-way merge.
> > If it does make merging more difficult then we loose the main benifit of
> > importing this stuff into our git repository - at which point we might as
> > well include a tarball and some .patch files.
> 
> There is git merge --squash but, yes, let's not do that.
> 
> I found a couple of ways to reduce the noise when viewing the history:
> 
>   - git log --first-parent
>     But commits merged from the stable branch to the master branch will
>     also be suppressed, so it's not ideal.
> 
>   - git log -- . ':!boehm_gc'
>     It's a bit of a mouthful but might be okay with an alias/script.
> 
> I'm fairly comfortable with submodules but it requires additional steps
> that other developers might not like.  It also makes the main repository
> incomplete of itself which is a bit undesirable.

I'm learning towards the submodule idea.  Especially if we put a small
autogen.sh script in the root directory of Mercury, this should pull in
submodules and then do aclocal -I m4 && autoconf.  This will reduce the
steps needed to build from git.

We would also fork the boehm gc repository and store it in the Mercury
project on github.

> 
> Another option would be do the merging work in a separate repository,
> as we would for a submodule, but then just copy the files into the main
> repository.

That could work, it's similar to what we've done before with CVS.


-- 
Paul Bone



More information about the reviews mailing list