[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