Subject: [boost] [build] improving the history
From: Vladimir Prus (ghost_at_[hidden])
Date: 2013-12-14 12:44:11
I've spent some time looking at history of Boost.Build git repository, and I think I've got a fairly
The problem statement is that in the converted repository, the top-level has nothing but a directory
called 'v2', which is rather ugly. While it can be fixed with 'git mv', it would mean that 'git log file'
will not show complete history unless the --follow option is passed, which is inconvenient. It appears
that graphical tools don't like moves much either. There were already moves in SVN, so even now,
running 'git log' on any file in engine/ won't return complete history without --follow. Further,
at some older revision, there are two copies of what was jam code then.
The most convenient solution for these problems is to edit history of the 'develop' branch, so that content
of top-level directory matches what was in 'v2' in SVN, and so that content of 'engine' matches Jam sources
through the years. This won't actually break any important references from the super-project, first because
they presumably are only to master branch, and second, because the commit objects will be still retained in
repository. I am not sure we need to rewrite the 'master' branch, as it's not used for day to day development.
Now, as soon as we're rewriting history, it might be good idea to change directory structure to
be more alike to the structure that other components have. The additional downside here is that the historical
versions will not be fully functional - specifically it will break references from examples and tests to
the rest of Boost.Build. But, I think it's worth the trouble - users can still obtain old, fully functional,
versions from the tags, or master branch (yet another reason for it not to be rewritten), while developers
will enjoy both clean directory structure and fully functional history on 'develop' branch.
So, the way I'd most like Boost.Build develop branch to look is this:
It has fairly clean structure, and running 'git log src/engine/jam.c' goes all the way to initial jam code
import. The original post-conversion state is stored at converted-develop tag.
Steven, Jurgen, what do you think? Any other concerns I have overlooked. I really would like to to get over
git games, and declare the repository to be ready, so unless I'll hear objections by the end of Monday,
I will force-push this to develop branch and adjust the super-project as necessary.
If anybody wants to try at home, the rewriting was done like this:
git filter-branch --prune-empty --tree-filter `pwd`/../rewrite.sh -f
where 'rewrite.sh' is attached. I also have a branch with less aggressively rewritten history, at
but sticking to it means we won't be able to rearrange things without creating problems in future.