In our previous episode, Graeme Geldenhuys said:
> To do it the "correct way", is a lot of work, hence the reason I
> stopped mirroring the fixes branches. What I mean by "correct way", is
> cherry-picking the commits from Trunk (master) and applying them in
> the fixes branch - thus it is one standard git repository (with
> alternate branches), is more efficient for git to work with, and uses
> less disk space. But the problem is, it can't be automated (I need to
> manually track what commits are merged by FPC developers, manually fix
> conflicts etc) and my free time is very limited.
I can try to create some form of automated feed of fixes tree commits +
items that are merged.
So assume fixes branch rev X merges revision T1,T2,T3 from trunk.
You then roughly would do
for X in all fixes revs to process since last processing do
begin
svn diff fixes branch X-1,X > temp.patch
cherry pick from git trunk to git fixes revs (e.g. T1 T2 T3)
git revert all changes to files but not mergeinfo (resolves all conflicts)
patch -p0 < temp.patch ( applies the manually merged fixes)
git push/commit whatever
end;
An innerloop for T1,T2,T3 separately is unfortunately not possible (since
manual fixes up might apply to all revs at once)
I'm not saying that I will have such info next week, but if you could test
if you could get such scenario done with GIT, I can see if I drag such info
out of the mergelog package in time. (which I'm still expanding)
I doubt it is the same as truly working through GIT (I'm not sure if
tracking of line changesets works even if you could all T<x> individually),
it might be already better since it is automated and has GIT level info per
fixes rev what revs were merged from trunk.
It assumes GIT can deal with mergeinfo a bit creatively and flexible though.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
