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, creators of DAML

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. If you are not the intended recipient, please delete this message.