<br><br><div class="gmail_quote">On 28 April 2012 18:57, Marco van de Voort <span dir="ltr"><<a href="mailto:marcov@stack.nl" target="_blank">marcov@stack.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">In our previous episode, Graeme Geldenhuys said:<br>
> To do it the "correct way", is a lot of work, hence the reason I<br>
> stopped mirroring the fixes branches. What I mean by "correct way", is<br>
> cherry-picking the commits from Trunk (master) and applying them in<br>
> the fixes branch - thus it is one standard git repository (with<br>
> alternate branches), is more efficient for git to work with, and uses<br>
> less disk space.  But the problem is, it can't be automated (I need to<br>
> manually track what commits are merged by FPC developers, manually fix<br>
> conflicts etc) and my free time is very limited.<br>
<br>
</div>I can try to create some form of automated feed of fixes tree commits +<br>
items that are merged.<br>
<br>
So assume fixes branch rev X merges revision T1,T2,T3 from trunk.<br>
<br>
You then roughly would do<br>
<br>
 for X in all fixes revs to process since last processing do<br>
   begin<br>
     svn diff fixes branch X-1,X > temp.patch<br>
     cherry pick from git trunk to git fixes revs  (e.g. T1 T2 T3)<br>
     git revert all changes to files but not mergeinfo (resolves all conflicts)<br>
     patch -p0 < temp.patch    ( applies the manually merged fixes)<br>
     git push/commit whatever<br>
   end;<br>
<br>
An innerloop for T1,T2,T3 separately is unfortunately not possible (since<br>
manual fixes up might apply to all revs at once)<br>
<br>
I'm not saying that I will have such info next week, but if you could test<br>
if you could get such scenario done with GIT, I can see if I drag such info<br>
out of the mergelog package in time.  (which I'm still expanding)<br>
<br>
I doubt it is the same as truly working through GIT (I'm not sure if<br>
tracking of line changesets works even if you could all T<x> individually),<br>
it might be already better since it is automated and has GIT level info per<br>
fixes rev what revs were merged from trunk.<br>
<br>
It assumes GIT can deal with mergeinfo a bit creatively and flexible though.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
fpc-devel maillist  -  <a href="mailto:fpc-devel@lists.freepascal.org">fpc-devel@lists.freepascal.org</a><br>
<a href="http://lists.freepascal.org/mailman/listinfo/fpc-devel" target="_blank">http://lists.freepascal.org/mailman/listinfo/fpc-devel</a><br>
</div></div></blockquote></div><br><br clear="all">How about SubGit - <a href="http://subgit.com">http://subgit.com</a> ?<br><br>I am always on the lookout for the next miracle cure :)<br><br>Disclaimer: sender of this email knows next to nothing about git and svn interoperability issues.<br>
<br><br><br><br>-- <br>Frank Church<br><br>=======================<br><a href="http://devblog.brahmancreations.com">http://devblog.brahmancreations.com</a><br>