[fpc-devel] FreePascal Git Repo and 2_6 branch

[Marco van de Voort]

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.