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