I am wondering if Graeme can update his FreePascal git mirror to include the 2_6 branches.

Thanks

David Jenkins

David Jenkins wrote

I am wondering if Graeme can update his FreePascal git mirror to include the 2_6 branches.

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.

What I can do in an automated fashion, is to simply mirror the 2.6 fixes branch as a separate git repository (with limited history - going back to when 2.6 fixes branch was started). If this would be sufficient, I can set it up on Wednesday when I am back in the office. That's no trouble.

In our previous episode, Graeme Geldenhuys said:

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.

How about SubGit - http://subgit.com ?

I am always on the lookout for the next miracle cure :)

Disclaimer: sender of this email knows next to nothing about git and svn interoperability issues.

Frank Church wrote

How about SubGit - http://subgit.com ?

No thanks.

I think "git svn clone" with --stdlayout parameter could be used to create a whole repository with all branches.
Then tracking branches in git repo should be created and later they can be "git svn rebase"d to latest revision.

This kind of mirror could be created anywhere. Now all the mirrors are part of Graeme's workload.

Regards
Juha

For my situation this would be sufficient.

I have some local patches that git-rebase does a nice job of plopping on the head of the branch whenever there are changes. Right now those patches are sitting on trunk but I would like to move them to fixes-2_6 and maintain them there.

I had started to do a 'git svn clone' of the fpc repository myself and after it ran for 16 hours wondered if there were a better way. Creating the limited history 2.6 fixes branch repository myself is probably also an option if you have better things to do.

Thanks

David