
Trac tickets with links to commits are the important case. If the commit IDs change, someone will have to run a script over the Trac database and rewrite all those links to testsuite commits to the new ones. Sounds possible, but it'll be at least a few hours work I'd guess. I'm in favour of removing the unnecessary binary blobs from the history so long as we can do it without any serious disruption. Cheers, Simon On 06/12/2013 12:50, Johan Tibell wrote:
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
mailto: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?
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs