[wildfly-dev] Handling history with the build split
Jason Greene
jason.greene at redhat.com
Tue Jun 17 23:33:23 EDT 2014
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
More information about the wildfly-dev
mailing list