[wildfly-dev] Handling history with the build split

[Darran Lofthouse]

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 ;-)

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
>