On 2013-12-09 at 09:34:23 +0100, Joachim Breitner wrote: > Am Montag, den 09.12.2013, 09:24 +0100 schrieb Herbert Valerio Riedel: >> What kind of links are you referring to btw? I don't see any clickable >> GHC SHA1 ids these days anymore... :-) > > well, people do write SHA1 ids in tickets comments directly. (At least I > do. And then I rebase my branch. And then the link is dead ;-))
...those links manually written into ticket comments will continue to work since they had to explicitly refer to the testsuite repo anyway (e.g. `[27c42f4022/testsuite]`) if they had any chance of working before, and even if we retain the old commit ids in ghc.git, those links would still point to the testsuite.git repo and not to ghc.git > But in contrast to the mailing list link issue, even if we rewrite the > testsuite before merging, it will be possible, although a bit more > tedious, to look up the corresponding new hash. What I don't understand yet is, why do we need to know the new hash ids at all? If we come across an old hash-id, aren't we just interested in finding the commitdiff (and possibly neighbor commits) it refers to? [...] > We could even check in the ID→ID mapping in the repo and have a easy to > discover ./testsuite/lookup-old-id script so that this is even less an > annoyance. > PS: What happens if we set up replace objects in the git repo that > cgit and trac are using: > https://www.kernel.org/pub/software/scm/git/docs/git-replace.html > Would that make the old links still work? That feature sounds *very* interesting to our problem at hand as it effectively allows to hide the real new SHA1 ids for the over 6000 "historic" testsuite commits (or put differently, it allows use to embed the oldid-newid mapping at the Git meta-data level); I'll experiment with 'git replace' to see if it could really work in our use-case. Cheers, hvr _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
