Whichever way to go, we should write down the options and consequences and communicating them widely enough so no core devs get surprised.

Commit IDs for the test suite are referenced in e.g. various Trac issues, on mailing lists (although rarely), and perhaps even in code.


On Fri, Dec 6, 2013 at 1:15 PM, Herbert Valerio Riedel <hvr@gnu.org> wrote:
On 2013-12-06 at 13:01:41 +0100, Johan Tibell wrote:
> When we merge in the testsuite repo, can we still keep the old commit IDs?
> They're referenced from all over the place.

...if we want to preserve the old testsuite's commit-ids, then we'll
have to live with carrying around those superflous large blobs in
testsuite's history nobody really needs, as afaik[1] we can't remove the
blobs w/o causing the commit-ids to change.

I'm not so much concerned about disk-space, but rather the wasted
network bandwidth involved (and yes, we're already suffering from that
now with the current testsuite.git). But I don't feel very strongly on
this one, if there's agreement that we want to keep around those dead
weights in the Git history in order to retain testsuite.git's original
commit ids *inside* ghc.git (nb: the old testsuite.git repo won't be
deleted and thus remain available, it just won't be pushed into
anymore).

Otoh, which use-cases exactly do you have in mind wrt the testsuite.git
commit-ids?


 [1]: maybe someone with more Git-foo knows a trick here?