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