Repository Reorganization Question

[Herbert Valerio Riedel]

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