on Wed May 22 2013, Dave Abrahams
on Wed May 22 2013, Jürgen Hunold
wrote: But this can easily be done after the conversion.
I think we already lost too much time with failed rewrite attempts, so let us get a working repository first. Then Volodya can test git mv v2/* . and report results. Afterwards, we can always try rewriting in a separate clone.
Rewriting _published_ history is most strongly discouraged by the Git people, for several good reasons. *If* there is to be any rearrangement, it should happen before the switchover, so it doesn't bork people who are doing work based on the history originally published.
However, I am loath to do any rearrangement that doesn't (reasonably) faithfully reflect how things were set up in the past. Otherwise, someone will check out an old state of the super-module and find that things have the wrong path relationships. Of course, path relationships will not match SVN anyway (because we don't have a modular layout in SVN), but people on this list made it quite clear that modularizing history was important to them, so I presume they want the Git history to reflect reality with maximal fidelity.
That said, if the consensus is that things should be rearranged in the build repository, we can do that. We just need clear and explicit instructions that cover what to do with *all* the paths that have been used in Boost.Build (including branches and tags) throughout time. As you can see from https://github.com/ryppl/Boost2Git/blob/master/repositories.txt#L2261 and following lines, just preserving the existing structure was nontrivial.
Caveat: what I mean by "preserving existing structure" is that branches that include just a slice of the tools/build + tools/jam hierarchy have all the files located in the same places where they appear under trunk/. That's the appropriate way to map things for Git. -- Dave Abrahams