Re: [boost] Git Modularization Review no vote heads-up

Hi Dave,

Gesendet: Donnerstag, 23. Mai 2013 um 07:28 Uhr Von: "Dave Abrahams" An: boost@lists.boost.org Betreff: Re: [boost] Git Modularization Review no vote heads-up

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.

Done this myself yesterday. Works like a charm, git blame shows undisrupted history after git commit shows "rename" with 100% on each file moved.

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.

Yes, the basic rule of git.

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.

Correct.

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.

That one starts with repository build : common_branches { submodule of "boost" : "tools/build"; content { "tools/build/" : "build"; "tools/jam/" : "jam"; } right? So, this now creates "tools/build/build" with the contents of "tools/build" and "tools/build/jam" with the contents of "tools/jam" which is long gone. The former is wrong, as it does not preserve the current structure despite the thing you wrote above. I think that a one-to-one mapping like: repository build : common_branches { submodule of "boost" : "tools/build"; content { "tools/build/" ; } is the way to go now. If something goes wrong, please put "tools/jam/" somewhere else. Btw. would repository build : common_branches { submodule of "boost" : "tools/build"; content { "tools/build/v2" ; } be the right way to move v2 one directory up? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! juergen.hunold@gmx.eu * voice: 0049 4257 300 ! Fährstraße 1 * fax : 0049 4257 300 ! 31609 Balge/Sebbenhausen * mobil: 0049 178 186 1566 ! Germany