<div dir="ltr"><div style><span style="font-family:arial,sans-serif;font-size:13px">Hello,</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">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.</span></div>
<div style><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><span style="font-family:arial,sans-serif;font-size:13px"><div style><span style="font-family:arial,sans-serif;font-size:13px">Ian explains the current workflow for collaborating with Cabal:</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div>* Initially ghc's Cabal repo is at the same commit as upstream</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">* We make a local commit 123 in Cabal to fix some bug</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">* Cabal upstream makes a commit 456 to fix the same bug differently</span><br style="font-family:arial,sans-serif;font-size:13px"><span style="font-family:arial,sans-serif;font-size:13px">* We jump to commit 456, in such a way that we don't end up merging</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px"> with our 123 commit every time we pull from Cabal in the future</span><br style="font-family:arial,sans-serif;font-size:13px"><div><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div style><font face="arial, sans-serif">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).</font></div>
<div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">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. </font></div>
<div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">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.</font></div>
<div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">2. The GHC sub-module will point to:</font></div><div style><font face="arial, sans-serif"> 2.1 some upstream commit, if we don't currently use any temporary changes;</font></div>
<div style><font face="arial, sans-serif"> 2.2 some commit on the `ghc-tmp-changes` branch, if we are depending on some temporary fix.</font></div><div style><font face="arial, sans-serif"><br></font></div><div style><font face="arial, sans-serif">3. To start a new set of temporary changes (i.e., our sub-module is currently pointing to upstream commit `111`)</font></div>
<div style><font face="arial, sans-serif"> 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.</font></div>
<div style><font face="arial, sans-serif"> 3.2 Make the change and commit it on branch `ghc-tmp-changes`, resulting in commit `222`.</font></div><div style><font face="arial, sans-serif"> 3.3 Update the sub-module to point to `222`.</font></div>
<div style><br></div><div style>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.</div><div style>
<br></div><div style>I hope this helps,</div><div style>-Iavor</div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style>
<br></div><div style><br></div><div style><br></div><div style><br></div><div style><br></div><div style><font face="arial, sans-serif"><br></font></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div></div>