Keeping GHC's history intact

[Iavor Diatchki]

Hello,

I'd noticed that occasionally my branch of GHC would fail to check-out due
to missing references to the Cabal repo.  For a while this was puzzling me,
because as far as I know we don't do rebasing of published changes, but as
I was reading another thread I found the problem.

Ian explains the current workflow for collaborating with Cabal:

* Initially ghc's Cabal repo is at the same commit as upstream
* We make a local commit 123 in Cabal to fix some bug
* Cabal upstream makes a commit 456 to fix the same bug differently
* We jump to commit 456, in such a way that we don't end up merging
  with our 123 commit every time we pull from Cabal in the future

The last step in this work-flow---where we jump directly from 123 to
456---loses information:  the Cabal repo has no way of knowing that some
previous version of GHC still depends on 123.  As a result, commit 123 can
get GC-ed, which breaks GHC's history (i.e., we can't go back to GHC as it
was back when it depended on 123).

I'd like to propose the following workflow for repos where GHC developers
need to make temporary changes that are not intended to be merged into
upstream.

1. Create a new branch 'ghc-tmp-changes' in the foreign repo (e.g., Cabal).
  This branch is where we'll make the temporary changes, and its history
will keep track of all previous temporary changes we made, so that our
history stays intact.

2. The GHC sub-module will point to:
   2.1 some upstream commit, if we don't currently use any temporary
changes;
   2.2 some commit on the `ghc-tmp-changes` branch, if we are depending on
some temporary fix.

3. To start a new set of temporary changes (i.e., our sub-module is
currently pointing to upstream commit `111`)
  3.1 Merge  `111` into `ghc-tmp-changes` by using strategy `theirs`.
This makes sure that `ghc-tmp-changes` is up to date.  If this is not the
first temporary change to make, then we can skip this step.
  3.2 Make the change and commit it on branch `ghc-tmp-changes`, resulting
in commit `222`.
  3.3 Update the sub-module to point to `222`.

4. When our temporary changes are no longer needed (i.e., they got fixed in
upstream in some other way), then we simply point the sub-module to
the relevant upstream commit.

I hope this helps,
-Iavor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130618/ce0ba88a/attachment.htm>