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?
Language Engineer */* +1 917 699 7663
*Digital Asset* <https://digitalasset.com/>, 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs