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

[Sebastian Godelet]

Hello,

In case I understood the problem correctly,
did you consider git sub-modules, e.g. as used in
https://github.com/SWI-Prolog/swipl-devel
such that the mercury repository would just link in a fork of the Boehm gc,
that way there is no pollution of the history I suppose

Cheers,

Sebastian

On 20 October 2014 18:16, Paul Bone <paul at bone.id.au> wrote:
> 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
> _______________________________________________
> reviews mailing list
> reviews at lists.mercurylang.org
> https://www.mercurylang.org/lists/listinfo/reviews