a better workflow?

Sebastian Graf sgraf1337 at gmail.com
Wed Jul 24 14:57:18 UTC 2019

I found that git worktree works rather well, even with submodules (well,
mostly. Even if it doesn't for some reason, you can still update and init
the submodules manually, losing sharing in the process).
See https://stackoverflow.com/a/31872051, in particular the GitHub links to
`wtas` alias.

I mostly do this:

$ cd ~/code/hs/ghc
$ cd pristine
$ git wtas ../pmcheck

and mostly just hack away. From time to time I seem to have issues because
of confused submodule references, but as I said above doing a `git
submodule update --init --recursive` fixes that. Cloning the root GHC
checkout is the most time-consuming step, after all.

Also I'm currently in the rather comfortable situation of having an 8 core
azure VM just for GHC dev, which is pretty amazing. Doing the same as Ben
here: Having a tmux open with one (or more) tab per checkout I'm working on
in parallel. VSCode is my editor of choice and seamlessly picks up any SSH
connection I throw at it. Can highly recommend that when you're on a rather
weak machine like a laptop or convertible.

Am Mi., 24. Juli 2019 um 14:03 Uhr schrieb Richard Eisenberg <
rae at richarde.dev>:

> On Jul 23, 2019, at 10:48 PM, Daniel Gröber <dxld at darkboxed.org> wrote:
> I don't think you ever mentioned -- are you already using `git
> worktree` to get multiple source checkouts or are you working off a
> single build tree? I find using it essential to reducing context
> switching overhead.
> This is a good point. No, I'm not currently. Some post I read (actually, I
> think the manpage) said that `git worktree` and submodules don't mix, so I
> got scared off. Regardless, I don't think worktree will solve my problem
> exactly. It eliminates the annoyance of shuttling commits from one checkout
> to another, but that's not really a pain point for me. (Yes, it's a small
> annoyance, but I hit it only rarely, and it's quick to sort out.) Perhaps
> I'm missing something though about worktree that will allow more, e.g.,
> sharing of build products. Am I?
> Thanks!
> Richard
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190724/dfdc76ac/attachment.html>

More information about the ghc-devs mailing list