Actually, I forgot to pull: git remote add tdammers git@gitlab.haskell.org:tdammers/ghc.git

git pull tdammers git checkout tdammers some-branch

And to post changes to, say, GHC's main repo: git push origin some-branch -- Artem On Tue, 25 Jun 2019 at 12:04, Artem Pelenitsyn wrote:

Dear Simon,

In order for submodules to work, you still have to jump through the main repo. That is,

git clone --recursive https://gitlab.haskell.org/ghc/ghc tdammers cd tdammers git remote add tdammers git@gitlab.haskell.org:tdammers/ghc.git git checkout tdammers some-branch

Dear ghc-devs, More generally, I'm actually wondering, why GHC's .gitsubmodules use relative paths. Why not make them absolute?

-- Best wishes, Artem

On Tue, 25 Jun 2019 at 11:52, Simon Peyton Jones via ghc-devs < ghc-devs@haskell.org> wrote:

...

What is the right procedure for cloning from someone else’s repo.

For example, I wanted to see what was going wrong for Tobias in #16615, so after some detective work I tried

git clone --recursive git@gitlab.haskell.org:tdammers/ghc.git tdammers

but I got lots of errors:

Cloning into '/home/simonpj/code/tdammers/libffi-tarballs'...

setsockopt IPV6_TCLASS 8: Operation not permitted:

...

GitLab: The project you were looking for could not be found.

fatal: Could not read from remote repository.

Please make sure you have the correct access rights

and the repository exists.

fatal: clone of 'git@gitlab.haskell.org:tdammers/libffi-tarballs.git' into submodule path '/home/simonpj/code/tdammers/libffi-tarballs' failed

Failed to clone 'libffi-tarballs'. Retry scheduled

Cloning into '/home/simonpj/code/tdammers/libraries/Cabal'...

setsockopt IPV6_TCLASS 8: Operation not permitted:

...

GitLab: The project you were looking for could not be found.

fatal: Could not read from remote repository.

Please make sure you have the correct access rights

and the repository exists.

fatal: clone of 'git@gitlab.haskell.org:tdammers/packages/Cabal.git' into submodule path

etc etc.

So:

- What is a reliable way to get a MR onto my machine to test? - If I make a fix, what is the workflow to push that fix back to the author -- presumably I can’t push to their repo?

Thanks

Simon

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

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.