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

Subject: Re: [boost] Git Modularization Review no vote heads-up
From: Jürgen Hunold (jhunold_at_[hidden])
Date: 2013-05-23 03:04:50

Hi Dave,

> Gesendet: Donnerstag, 23. Mai 2013 um 07:28 Uhr
> Von: "Dave Abrahams" <dave_at_[hidden]>
> An: boost_at_[hidden]
> Betreff: Re: [boost] Git Modularization Review no vote heads-up
>
>
> 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.

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_at_gmx.eu
* voice: 0049 4257 300       ! Fährstraße 1
* fax  : [phone]       ! 31609 Balge/Sebbenhausen
* mobil: 0049 178 186 1566   ! Germany