On 2013-12-09 at 13:31:15 +0100, Austin Seipp wrote:
It seems that while most people are in favor of migrating and preserving the history there are a few sticky bits concerning some of the minor details. So I think the discussion should continue, but we clearly shouldn't pull the trigger quite yet. testsuite etc will live on for a while longer.
In the mean time I've updated the branch http://git.haskell.org/ghc.git/log/refs/heads/wip/T8545 to include the full testsuite.git history, with the history rewritten as if the files have been always in the 'testsuite/' folder, and with the blobs removed; moreover I've tweaked the sync-all script to check for a left-over testsuite/.git folder, to remind users to move it out of the way. Thus, with the current state of the T8545 branch, - `git blame testsuite/tests/typecheck/should_compile/all.T` works as expected - `git log testsuite/` as well as `cd testsuite/ && git log .` works as expected - The cleaned-from-large-blob testsuite.git history adds only about 10MiB packed transfer size (as opposed to the full ~30MiB it would require if the blobs weren't removed) - The historic/original testsuite.git commit hash ids are not retained in ghc.git, as they continue to exist in the "legacy" testsuite.git (where all current Trac hyperlinks will continue to refer to anyway)[1]; - When peferming a `sync-all pull` (with the old `sync-all` script) developers will get the new ghc.git-tracked `testsuite/` folder and on the next `sync-all` invocation (which will use the updated sync-all script for the first time) they'll be reminded/forced to move away a possibly left-over `testsuite/.git` folder. - At some point after the switch, `testsuite.git` should be set read-only (for the `master` branch at least). So, what are the current sticky bits left over given the proof-of-concept in wip/T8545 that still need to be addressed? [1] If we really need this for our development workflows, we could still attempt to make use of the `git replace` facility in the future to overlay the old commit ids. But if we don't need it (and from the discussion so far I don't see a requirement for that), it's better to keep it simple.