[wildfly-dev] Handling history with the build split

[Jason Greene]

Yeah the main dist branch should probably be a preserved history for that reason. 

On Jun 17, 2014, at 8:13 PM, Brian Stansberry <brian.stansberry at redhat.com> wrote:

> One thing that occurred to me is the main repo will have the 8.x branch, 
> which was split off pretty close to when you started this work. So 
> switching to that branch makes it fairly easy to see the full context of 
> a commit if it's lost with git-replace.
> 
> On 6/17/14, 7:25 PM, 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
>> 
> 
> 
> -- 
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat