On Tue, Jun 25, 2019 at 5:29 AM Simon Peyton Jones via ghc-devs < [email protected]> 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 [email protected]: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.
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
