
Thanks Ben, Just to clarify: By history I mean not just commits, but GitHub issues and PRs as well -- together they contain a lot of valuable interlinked information for GHC/Hadrian developers.
That is pretty much precisely the use-case which git subtree was designed to address. This will allow us to have Hadrian, with history, in the GHC tree and you can continue to develop it on GitHub until things have stabilized.
Sounds great. I haven't used git subtrees before, so I'll need to do some reading, but if everyone is happy with merging Hadrian as is, I can prepare a patch over the weekend!
Cheers,
Andrey
-----Original Message-----
From: Ben Gamari [mailto:ben@well-typed.com]
Sent: 19 October 2017 20:50
To: Andrey Mokhov
Hi Mathieu,
Yes, in principle we can merge right now, as long as it's clear that Hadrian still requires more work before taking over.
My only concern is that merging will make it more difficult for us to quickly iterate on Hadrian: the GitHub workflow is more convenient (at least for me) than the Phabricator one. Perhaps, we can keep Hadrian on GitHub as a submodule? This also has the advantage that we can keep all existing references to GitHub issues/PRs without migrating everything to GHC Trac. It would be very unfortunate to lose all history during the merge.
Okay, so if we want to preserve history then I would suggest that we go the subtree route. That is pretty much precisely the use-case which git subtree was designed to address. This will allow us to have Hadrian, with history, in the GHC tree and you can continue to develop it on GitHub until things have stabilized. The only question is how to ensure that the subtree remains up-to-date. Cheers, - Ben

Andrey Mokhov
Thanks Ben,
Just to clarify: By history I mean not just commits, but GitHub issues and PRs as well -- together they contain a lot of valuable interlinked information for GHC/Hadrian developers.
Well, the GitHub repo will still exist. Is that enough? Cheers, - Ben
participants (2)
-
Andrey Mokhov
-
Ben Gamari