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 ;-)
Yes, that will still exist. What may be lost is modifications to other
files that were done in the same commit but that are now part of a
different repo (although you will still be able to just look them up in
the old repo).
Stuart
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
>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev