Re: [boost] [build] improving the history

Subject: Re: [boost] [build] improving the history
From: Edward Diener (eldiener_at_[hidden])
Date: 2013-12-18 11:56:23

On 12/18/2013 2:10 AM, Vladimir Prus wrote:
> On 17.12.2013 22:33, Vladimir Prus wrote:
>> On 14.12.2013 21:44, Vladimir Prus wrote:
>>>
>>> I've spent some time looking at history of Boost.Build git
>>> repository, and I think I've got a fairly
>>> reasonable outcome.
>>>
>>> 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:
>>>
>>>      https://github.com/boostorg/build/tree/develop-rewritten-2
>>>
>>> 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.
>>
>> I am gonna switch 'develop' to this version tomorrow morning, Moscow
>> time.
>
> It is done:
>
>      https://github.com/boostorg/build/tree/develop
>
> Between I've started playing with rewrite and today, Juergen merged a
> few pull requests. I've created
> a tag to point at develop branch state right before I've force-pushed my
> changes, which is prerewrite-develop,
> and I believe all of the commits are now on the rewritten branch.
>
> Then, I've merged to master in a way that makes master's tip tree be
> equal to develop's tip tree, while still recording
> current tips of master and develop as parents, as follows:
>
>      $ echo "Merge develop" | git commit-tree
> cb54f66965b5b8571cd1ab28939666034552072d -p
> 87098597c066240567d3b5556e0689a7c9d5720f
>      -p dc428e2ab3bf198ebc8a53b5b25d09fa7b29e4a1
> 8c178d6bdbe352b487e9cdb88fd9773a708637ea
>      $ git reset --hard 8c178d6bdbe352b487e9cdb88fd9773a708637ea
>      $ git commit --amend
>      (edit log message to be more useful)
>
> The whole point of this exercise was to avoid more forces pushes. Also,
> it makes further merges from develop to master just work.
> It does make master history a bit more messy, but it's not it's useful
> for anything anyway.
>
> Now, if you've got clones of build repository, some work is required.
>
> - If you have local clone with no changes on 'develop' branch, do:
>
>      git fetch
>      git checkout develop
>      git reset --hard origin/develop
>
>
> - If you have local clone with some changes on 'develop' branch, do:
>
>      git fetch
>      git branch develop-old develop
>      git checkout develop
>      git reset --hard origin/develop
>      git log develop-old
>      # for every local change, do
>      git cherry-pick <commit-id>
>
> - If you have local clone of a github clone, do this:
>
>      git remote add boostorg git_at_[hidden]:boostorg/build.git
>
>    and then do everything as above, replacing origin with boostorg. At
> the end,
>    do 'git push -f'
>
> If anybody has any issues, drop me a line or talk to me on IRC and I'll
> help.

Are you talking about just getting the latest changes to Boost Build 
submodule from its develop branch ?