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

Subject: Re: [boost] Git Modularization Review no vote heads-up
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-05-23 02:15:32

on Wed May 22 2013, Dave Abrahams <dave-AT-boostpro.com> wrote:

> on Wed May 22 2013, Jürgen Hunold <jhunold-AT-gmx.eu> 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