Why not move Lazarus Project to Git?

[JuhaManninen]

From this mail thread :
  http://free-pascal-general.1045716.n5.nabble.com/Semi-OT-Git-format-patches-don-t-seem-to-work-tt4868112.html
I understand there are many ways to solve the diff format problem.
One is "patch -p1 < git.diff".
One is the script BigChimp also copied here.
One is a WebKit script shared by Florian Klämpfl :
  http://svn.freepascal.org/svn/fpcbuild/scripts/florian/unix/svn-apply
And one is (I believe) the new SVN 1.7 version. 

It would be strange if this kind of problem wasn't solved somehow. We are solving more difficult problems all the time.
It is important to solve it for people who like to maintain their local branches and commits with git. It is a nice tool for that.

Maintaining local branches is not the same as distributed development model which is the other potential benefit of git.
It would be nice to try git for it. If someone makes branches I will follow them.
But remember, git does not magically improve code quality, the main challenge is still the creation of good code.
I am personally happy with my tool-chain now, although git is only used for local branch and commit management.

Juha

[marcov]

SVN 1.7 apparently support normal unidiff patches now.

http://subversion.apache.org/docs/release-notes/1.7.html#patch

Not sure if it can skip all the GIT header stuff, but it may work, if people just use diff to create a patch? (not tested)

The patch.exe we distribute on Windows is archaic (2005 or so). IIRC this is because this is the last mingw version, newer versions are msys.

[felipemdc]

One is "patch -p1 < git.diff".

A massive amount of errors with patch from Free Pascal

One is the script BigChimp also copied here.

That requires GIT, I don't have it.

One is a WebKit script shared by Florian Klämpfl :
  http://svn.freepascal.org/svn/fpcbuild/scripts/florian/unix/svn-apply

That's for Unix, my patch is for Windows.

[99Percent]

The brute force method described here: http://stackoverflow.com/questions/708202/git-format-patch-to-be-svn-compatible seems pretty failsafe.

• Make two clones of your repo
• In one clone check out your latest stuff
• In the other clone checkout whatever is equivalent to the svn upstream. If you have planned ahead you have a copy of svn upstream on its own branch, or you have tagged the last svn version. If you have not planned ahead, use the date or gitk to find the git SHA1 hash that most closely approximates the svn state.
• Now compute a real patch by running diff -r over the two clones.

[Vincent Snijders]

I can contact Graeme for that. Does someone else have a server available for this purpose in case Graeme  is busy and can't change it? I personally don't have.

We could create a Git mirror at SourceForge. There is SVN mirror for Lazarus already on SourceForge.

[JuhaManninen]

We could create a Git mirror at SourceForge. There is SVN mirror for Lazarus already on SourceForge.

How to do it? Does SourceForge have a mirroring service so that their server updates the repository automatically?
In case of Graeme's mirror, he has a scripts on his own server to send new SVN updates to the mirror.

Juha

[Vincent Snijders]

We can add such a script on one of our servers too.