On Oct 20, 2017, at 6:24 PM, Herbert Valerio Riedel wrote:

Hi Moritz (et al.),

On 2017-10-20 at 09:32:29 +0800, Moritz Angermann wrote:

...

a) why a git subtree if we keep working on github with hadrian, wouldn't that imply using a submodule? We use submodules for all the other ghc boot libs that are not part of the tree and are developed on github as well, no? As far as I understand a subtree, it's essentially integrating everything into the main tree. So this looks more like the submodule to subtree conversion, when hadrian development is switched over to phabricator?

Fwiw, using a submodule makes sense imho if hadrian is supposed to remain a submodule on the long-term; as transitioning from submodule <-> non-submodule is something Git doesn't handle to well automatically (we've had fun with that when we restructured ghc.git into the current structure...)

Also, a submodule has the benefit of ticket references clearly referring to a different numbering namespace w/o having to rewrite all ticket & commit-hash references (which is often overlooked; I for one tend to refer quite often to other commit shas in my commits, and they also result when you 'git cherry-pick -x')

So, what's the long-term plan for Hadrian repo-wise? Is it going to remain externally maintained on GitHub, or will it be integrated into GHC HQ's infrastucture which means using Phabricator (which may pose its own challenge, as Phabricator, like Trac, uses globally unique ticket numbers, rather than per-project numbering)?

If it is to be a submodule, we (and by that I mean myself; it doesn't take long) also need to setup mirroring from snowleopard/hardian to git://git.haskell.org, and from there to to github.com/ghc/hadrian for technical reasons.

I would assume that hadrian will be developed on github for a while, to not disturb the current workflow. But I'm happy to be corrected, when wrong here. After reading up on git-subtree[1][2], which sounds to me like subsuming one repo in another one and requiring a set of different commands to handle it. Maybe I'm just too used to git submodules. But as all the other externals in the ghc tree are submodules, I'd prefer the consistency. Knowing myself, I'd probably screw up pushing changes back upstream into hadrian if its workflow is different from e.g. the libraries, ... libffi-tarballs with the orphan branches is already something that needs to be taken special care of...

...

b) should we really hardcode the full url to hadrian tickets? wouldn't hadrian/#xxx suffice? Assuming for a moment hadrian would move into the github.com/haskell org or something, while the linkes would likely (due to githubs url redirection) keep on working, until someone recreates a snowleopard/hardian repo, but not necessarily correct anymore.

Note that GitHub doesn't support the abbreviated hadrian#xxx syntax; you *have* to prefix it by the organization/user, in order for GitHub to recognize a ticket reference; i.e. you *have* to use one of

- https://github.com/snowleopard/hadrian/issues/123 (or possibly .../pull/123)

- snowleopard/hadrian#123

- #123

- GH-123

for GitHub to recognize the issue reference.

anything else won't be recognized.

Moreover, github.com/haskell/ is not a good place for Hadrian since it's a too GHC-specific tooling; if anywhere, it would rather end up together with the other GHC repos in the /ghc/ org at https://github.com/ghc/hadrian (or something slightly different; we need reconcile this with our GHC mirroring scheme; that's may be a bit tricky).

I didn't specifically care about github auto-linking features here. Primarily about giving tickets a prefix. And not necessarily hardcoding some github url into ticket numbers. Cheers, Moritz -- [1]: https://www.atlassian.com/blog/git/alternatives-to-git-submodule-git-subtree [2]: http://alistra.ghost.io/2014/11/30/git-subtree-a-better-alternative-to-git-s...