Repository Reorganization Question

[Herbert Valerio Riedel]

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.