Cloning

Shayne Fletcher shayne.fletcher at daml.com
Tue Jun 25 10:31:25 UTC 2019


On Tue, Jun 25, 2019 at 5:29 AM Simon Peyton Jones via ghc-devs <
ghc-devs at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190625/fbc374b0/attachment.html>


More information about the ghc-devs mailing list