Re: [boost] [build] improving the history

Subject: Re: [boost] [build] improving the history
From: Vladimir Prus (ghost_at_[hidden])
Date: 2013-12-18 12:02:38

On 18.12.2013 20:56, Edward Diener wrote:
> 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 ?

Yes. If you try to update an existing clone, you will likely get an error today.

- Volodya