On Tue, Jun 25, 2019 at 5:29 AM Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote:
Thanks. I think I understand. The model is
- Always start from a clone of the main repo; do not attempt to clone anyone else’s - Add the extra repo as a remote - Check out a branch from it.
I had not previously understood that -- thanks
That's exactly it. My work finds me doing this sort of thing quite a lot. I don't know if my (the following) approach is overkill however, it works reliably for me. ``` # Clone the main repo git clone https://gitlab.haskell.org/ghc/ghc.git # Add remote git remote add tdammers git@gitlab.haskell.org:tdammers/ghc.git # Get remote's branches git fetch tdammers # Roll the main repo back to where tdammers /some-branch started git checkout `git merge-base tdammers/some-branch master` # Retrieve sub-modules as they were at that point git submodule update --init --recursive # Now switch to the remote branch git checkout -t tdammers/some-branch ```
More generally, I'm actually wondering, why GHC's .gitsubmodules use relative paths. Why not make them absolute?
I continue to wonder about that and if switching to absolute paths might remove this wrinkle. Can anyone chime in? -- *Shayne Fletcher* Language Engineer */* +1 917 699 7663 *Digital Asset* https://digitalasset.com/, creators of *DAML https://daml.com/* -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.