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

Paul Bone paul at bone.id.au
Mon Oct 20 21:16:44 AEDT 2014


On Mon, Oct 20, 2014 at 03:29:48PM +1100, Peter Wang wrote:
> On Fri, 17 Oct 2014 17:29:03 +1100, Paul Bone <paul at bone.id.au> wrote:
> > 
> > Rather than presenting a diff for review, I'd like to present my goals and
> > workflow for upgrading Boehm GC for review.  I'm looking for comments on
> > whether this is how we should track Boehm GC, as well as a review of the
> > process that I've used (attached).
> > 
> > Now that we use git to manage Mercury, I've attempted to upgrade Boehm GC
> > "the git way".  This should be reviewed by someone with a solid
> > understanding of git who might see a caveat that I havn't.
> > 
> > what I've attempted to do here is to import the git history of boehm GC into
> > our repository.  Then upgrading git in the future is done by adding the
> > boehm_gc repository as a remote, fetching changes, and merging them into our
> > master branch.  This may be convenient but the drawback is that we will then
> > store Boehm GC's history in our repository, which is not necessary and makes
> > the repository larger (I use a local mirror (a bare repository) I wonder if
> > other developers do).  I've attached an updated
> > compiler/notes/upgrade_boehm_gc.html file that documents the process I
> > followed, could someone review it please?
> > 
> > An alternative method to maintain Boehm GC would be to distribute an
> > upstream tarball and store in git a set of patches that should be applied to
> > the tarball after it is unpacked but before it is built.  This may be more
> > difficult to maintain (we won't have git's help when patches conflict after
> > upgrading boehm) but it means keeping our repository smaller.
> 
> Hi Paul,
> 
> I cloned both your repository (74.19 MiB) which has other stuff besides,
> and the official repository (70.76 MiB).  The size difference should be
> irrelevant.
> 
> It's a bit annoying that git log or gitk without any other arguments
> will show commits that I'm not really interested in.  From that POV,
> I'd rather see all of Boehm GC's commits squashed together.  Perhaps
> there is some way to mitigate that problem?

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.

> 
> BTW I noticed a couple of problems with the commit
> "These are miscellaneous changes made by Fergus Henderson"
>   - there is a conflict marker in misc.c.

I think i found this and fixed it in a subsequent patch, but I can rebase it
to tidy it up.

>   - README.debugging comes directly from Boehm GC upstream.

I didn't notice this but I'll take a look.

Thanks.

-- 
Paul Bone



More information about the reviews mailing list