
Just on this detail in the previous mails: On 6/25/19 10:00 PM, ghc-devs-request@haskell.org wrote:
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?
I remember the relative paths for submodules were added to make working with several clones of the GHC repo (to lower rebuild cost for simultaneous branches or similar) easier. With relative paths, one can make a second local clone from the first one and all references to all submodules will share local data. That said, this does get in the way sometimes. I changed back to absolute paths in my GHC fork quite a while back. / Jost

Hello Jost,
Thanks for researching this! In fact, Arnaud did his own research on this
topic and submitted !1309 [1] to switch to the absolute paths. The MR has
been approved by Ben swiftly and now awaits merging.
I believe we should default to the common case, which is to use abs paths
making the life of, presumably, many people easier, and let those who
understand submodules hack their way through them.
[1]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1309
--
Best wishes,
Artem
On Mon, 1 Jul 2019 at 12:17, Jost Berthold
Just on this detail in the previous mails:
On 6/25/19 10:00 PM, ghc-devs-request@haskell.org wrote:
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?
I remember the relative paths for submodules were added to make working with several clones of the GHC repo (to lower rebuild cost for simultaneous branches or similar) easier.
With relative paths, one can make a second local clone from the first one and all references to all submodules will share local data.
That said, this does get in the way sometimes. I changed back to absolute paths in my GHC fork quite a while back.
/ Jost
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Well this is an unexpected and most welcome development. Way to go Arnaud!
On Mon, Jul 1, 2019, 06:53 Artem Pelenitsyn
Hello Jost,
Thanks for researching this! In fact, Arnaud did his own research on this topic and submitted !1309 [1] to switch to the absolute paths. The MR has been approved by Ben swiftly and now awaits merging.
I believe we should default to the common case, which is to use abs paths making the life of, presumably, many people easier, and let those who understand submodules hack their way through them.
[1]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1309
-- Best wishes, Artem
On Mon, 1 Jul 2019 at 12:17, Jost Berthold
wrote: Just on this detail in the previous mails:
On 6/25/19 10:00 PM, ghc-devs-request@haskell.org wrote:
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?
I remember the relative paths for submodules were added to make working with several clones of the GHC repo (to lower rebuild cost for simultaneous branches or similar) easier.
With relative paths, one can make a second local clone from the first one and all references to all submodules will share local data.
That said, this does get in the way sometimes. I changed back to absolute paths in my GHC fork quite a while back.
/ Jost
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- 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.
participants (3)
-
Artem Pelenitsyn
-
Jost Berthold
-
Shayne Fletcher