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(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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.