[wildfly-dev] Handling history with the build split

[Stuart Douglas]

Darran Lofthouse wrote:
> Does the modified history contain enough information to do 'git
> annotate' - personally that is my main use of history to find out why on
> earth a line of code exists ;-)

Yes, that will still exist. What may be lost is modifications to other 
files that were done in the same commit but that are now part of a 
different repo (although you will still be able to just look them up in 
the old repo).

Stuart

>
> Having said that git is not the best at preserving history after
> refactoring and we have been able to cope with that in numerous places.
>
> Regards,
> Darran Lofthouse.
>
>
> On 18/06/14 01:25, Stuart Douglas wrote:
>> Hi all,
>>
>> So something we have been thinking about is how best to handle history
>> when doing the split, there were three obvious options that we looked at:
>>
>> 1) Copy the repo for each split, and just delete what is no longer needed.
>>
>> This means that you have full history, however each repo is 130Mb+, so
>> once you have 4 or more repos you are looking at a very large amount of
>> data to checkout a full WF server, which will probably put off potential
>> contributors.
>>
>> 2) Clean break
>>
>> Copy the files into a core repo, and just have a clean break, which
>> means that if you want to view history you will need to refer to the
>> original WF repo, which is not great (I know I use history and git
>> annotate a lot). This also means that it looks like the whole server was
>> added by one person in a single commit, which is not great.
>>
>> 3) git filter-branch
>>
>> We use the filer branch command to filter out all non-relevant history.
>> This means most history is intact, however you do loose the full context
>> of the commit if it modified subsystems that have been moved into
>> separate repos.
>>
>> It looks like it should be possible to append the old commit sha to the
>> message on a new line, which will make it easy to look up the old commit
>> if you need to see the full context.
>>
>>
>>
>> The interesting thing is that options 2) and 3) can also be used with a
>> little known command called 'git replace' (which is basically a
>> replacement for grafts), to basically graft the full history over the
>> top of the truncated/rewritten history. Basically if you care about the
>> full history you will be able to run a script, and it will graft the
>> complete WF history into your repo, so any command that works with
>> history will show each commit in its entirety.
>>
>> I think we should use option 3) combined with 'git replace'. This means
>> that the repo will be much smaller, and contain a rewritten version of
>> history that should be enough for most people. If anyone needs a full
>> history (e.g. when doing backporting) all that will be required is
>> running a simple script to replace the fake history with the real thing.
>>
>> Comments?
>>
>> Stuart
>>
>>
>>
>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev