[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