Why not move Lazarus Project to Git?

[Ask]

Yeah, and then have the patch rejected (or blindly applied despite its shortcomings) because it is too large to review. This is one of the serious barriers for Lazarus/fpc development.

How is GIT any different here? If you merge stuff which was not properly tested you will get into trouble. You still need to test and review everything. The real issue not at all GIT vs SVN it is simply that we lack resources in terms of patch testing and regression and smoke testing for patches.

The difference is that git allows me to:
continue development while the first patch(es) are reviewed,
organize patches into series for easier review,
efficiently re-generate patches to take into account the feedback,
efficiently work on several variants of the same feature and on several features concerning the overlapping set of files,
disentangle unrelated changes to the same file before committing,
etc, etc...

Just look at the current unicode string mess in FPC trunk --
and this is a feature developed by core team, not some outside contributor!

Not at all related to SVN vs GIT.
The feature was developed in a branch and then merged into trunk to get feedback, to be able to move it forward, because otherwise no-one tests the branches. How would GIT solve this? By not merging?

No, by allowing to publish, review and change the patch series before the final merge, by merging
it in the step-by-step fashion instead of all-at-once, so that the breakage could be limited.

I can heartily recommend cursory reading of Linux kernel and git mailing list, just looking at the
development and release processes involved -- these sources have taught me more about
the software engineering then all previous experience in the industry.

[JuhaManninen]

In SVN branching is very easy, but it is a central approach. What GIT adds is that people can maintain branches on their own local computer. (or local server).
That simplifies life for them somewhat.

Yes, that is why I wrote "local branches". They make it much more comfortable to experiment with code. You should try it!
I can only guess how other developers maintain their experimental changes, involving many features.

No, that only is when the branches are on the (main) server. For branches on 3rd party computers, it goes via patches again.

But this is not GIT specific, and was already experimented with by Florian with his mercurial mirror in, what was it, 2007?

The problem is that it is not simply "convert to git and get this one advantage", but that there must be a tremendous struggle
to keep up the current level, and conversion effort to deal with things that work differently in GIT (e.g. the missing of easy ,
sequential revision numbers, in favour of random cryptic hashes, lineendings etc etc).

For the conversion effort needed, core can probably manual edit and apply tens of thousands of patches, if not more.

Marco, you didn't read my post properly. I did not even suggest converting Lazarus repo to use git.
I suggested that people could work together using git, and someone with SVN commit rights could apply the possible results. I even volunteered to do so.

It is very much git specific. And no, branches on "3rd party computers" would not need to use patches then!
Instead the "3rd party person" would send me a mail telling he has a cool new feature and asks me to pull it. I do "git pull marco" (or something) and I have the feature ready to be tested. If "marco" did a good job I will merge the code immediately to my branch. Also "marco" can pull from me to test something.
When pulling, git recognizes local changes that were merged by other person and keeps the history clean.

Mercurial follows the same concept, how come you didn't know it?

Juha

[marcov]

Marco, you didn't read my post properly. I did not even suggest converting Lazarus repo to use git.
I suggested that people could work together using git, and someone with SVN commit rights could apply the possible results. I even volunteered to do so.

Then go ahead. But that is mere redistribution of work within git users, it has nothing to do with the subject.

It is very much git specific. And no, branches on "3rd party computers" would not need to use patches then!
Instead the "3rd party person" would send me a mail telling he has a cool new feature and asks me to pull it. I do "git pull marco" (or something) and I have the feature ready to be tested. If "marco" did a good job I will merge the code immediately to my branch. Also "marco" can pull from me to test something.
When pulling, git recognizes local changes that were merged by other person and keeps the history clean.

I do know. You need to save a git-pull request to file, and then git pull for that, and check the result is clear (in the working copy)

But IMHO there is no difference between storing the git-pull request (from mail, or mantis) and then getting the changest  via GIT, or directly saving the diff to file from mantis/mail.

[avra]

I suggested that people could work together using git, and someone with SVN commit rights could apply the possible results. I even volunteered to do so.

+1 for this. It would keep both SVN and GIT users happy, and provide more patches in a long run. Many people are lazy to do ping-pong mails to have their patch accepted if number of mails is much greater then 1. Even if patch is not accepted to be moved to SVN, we would have a centralized place where experimental patches are stored. Forum will also benefit, since anyone could publish a GIT link instead of source attachments.

[JuhaManninen]

+1 for this. It would keep both SVN and GIT users happy, and provide more patches in a long run. Many people are lazy to do ping-pong mails to have their patch accepted if number of mails is much greater then 1.

I think you mean people are lazy to create new modified patches and make them merge cleanly into the latest trunk.
With SVN it is a pain. I experienced it with some big patches before I got commit rights myself. Uhhh... bad!
The mail communication itself remains important. Actually it becomes more important in a distributed work flow.

Even if patch is not accepted to be moved to SVN, we would have a centralized place where experimental patches are stored.

No no and no!
A distributed system does NOT have a centralized place. That is the whole idea.
It supports a "network of trust" model which is part of natural human behavior.
You trust some people more than you trust some other people.

It makes the problem of "commit rights" to disappear. In a pure distributed model nobody has commit rights, except for his own local repository.

It gives a new meaning to term "fork". Usually a project fork is considered a serious and offensive act.
In a distributed system everybody has a forked version but in most cases nobody cares.
For example Linux kernel has maybe tens of thousands of forks but people only follow the fork of Linus Tornvalds because they trust him.
If Linus goes mad and makes a bad kernel, finally people start to follow someone else's fork.

Forum will also benefit, since anyone could publish a GIT link instead of source attachments.

Again no. A git link makes sense only to people who have configured git for that person's repository.
Such configuration may be tricky. I never did it myself. You must solve problems with dynamic IP addresses etc.
It will only help people who take the effort to configure it and then really want to experiment with many branches.
Not many people will do it, I am sure.

The main problems in SW development still remain. I agree with Marco and Felipe with that.
It still needs some effort and understanding to create code for a big project. Git does not change that. It only makes some technical details easier.

I copy the link for Linus Google talk here after all. It gives a good idea of the distributed model.
He likes to be provocative, so please ignore the SVN bashing part. Things are not so black-and-white.

http://www.youtube.com/watch?v=4XpnKHJAok8

Juha

[JuhaManninen]

Hi again

Thinking of it more, GitHub supports our needs well.
A person can create only one repository there for free, but the number of forked repositories is unlimited.
It means anyone can fork the Lazarus mirror repository.
Then anyone else can follow the branches of that person, using git in his own computer.
The model is pretty much distributed although there is a server involved.
The server solves the problem of configuring dynamic IP addresses for git.

So, those who are interested, please create a fork and start experimenting with git branches and git rebase etc.

https://github.com/graemeg/lazarus

I have sent a mail to the mirror's maintainer (Graeme) asking if master branch could follow trunk and if all SVN branches could be included.
Yet, the current mirror is also very usable. Just go ahead!

Juha

[marcov]

No no and no!
A distributed system does NOT have a centralized place. That is the whole idea.
It supports a "network of trust" model which is part of natural human behavior.
You trust some people more than you trust some other people.

Sorry, I was talking about application of a revision system, not about the hippie advocatism surrounding it:-)

This is exactly why above, I stressed the application within a real project, to avoid this kind advocacy that wants to describe a system that is 98% the same as something fundamentally different based on a rare (or non existent) usecase.

 

[Ask]

Thinking of it more, GitHub supports our needs well.
A person can create only one repository there for free, but the number of forked repositories is unlimited.

GitHub allows unlimited public repositories.
It requires a payment for private ones.

[Leledumbo]

Thinking of it more, GitHub supports our needs well.
A person can create only one repository there for free, but the number of forked repositories is unlimited.

Try bitbucket then, it recently supports Git after Mercurial only support for years. I vote for Mercurial though, since it's more platform neutral and has better merging algorithm which works 90% of the time.

[99Percent]

This is a very a good video tutorial of Git http://excess.org/article/2008/07/ogre-git-tutorial/

[JuhaManninen]

Try bitbucket then, it recently supports Git after Mercurial only support for years. I vote for Mercurial though, since it's more platform neutral and has better merging algorithm which works 90% of the time.

If someone creates a Lazarus mirror in BitBucket and people start developing branches there, I promise to learn to use Mercurial. It is conceptually similar to Git.
I don't believe its merge can be much better than Git's but the platform neutrality is a valid issue. Git traditionally works better on Linux. Windows support has improved but still for example git-svn link didn't work when I tried it. I develop mostly on Linux, currently under VirtualBox because of web connection issues.

My main message now is that all the pieces already exist for developing Lazarus using the distributed model and tools.
The git mirror can be forked anytime by anyone who really wants to do so. Graeme promised to change the master branch to follow trunk which makes it still easier.
There has been a problem with svn / git formatted patches. I have promised to upload valid code to SVN using git-svn link which means the process becomes as easy as it can be.

I don't know why the debate is always between SVN and Git. There are many other RCSs out there.
In case of Lazarus development the question has became highly political. The same arguments are repeated again and again.
Nobody seems to realize that these 2 systems can be used side by side without any real problems.

If I promise to help with the remaining issue which is uploading changes to Lazarus trunk, then the political problem should go away. Does it? I don't know.

Juha

[felipemdc]

If I promise to help with the remaining issue which is uploading changes to Lazarus trunk, then the political problem should go away. Does it? I don't know.

We are left with the practical problems then. You cannot simply commit all patches, usually those need to be first reviewed by the maintainer of that particular part of Lazarus and very frequently they need to be modified. Just now I got a patch which was made with git which uses a format which svn cannot recognize =( Passing the patch for you to apply is no good solution, because the patch cannot be applied as it is and I am working on the issue and would like to apply it myself with my changes. But the different format is a problem, as I have no tools to apply it in my machine.

What would really help is a converter git diff -> svn diff. Ideally written as a CGI application in fpweb. Then we could host it somewhere (even sourceforge, for example) and convert patches.

[Martin_fr]

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)

[felipemdc]

SVN 1.7 apparently support normal unidiff patches now.

But GIT does not use unidiff. It uses something similar, but particular to it.

Unified Diff is the format that SVN uses.

but it may work, if people just use diff to create a patch? (not tested)

Plain diff always worked, the problem is people using "git diff"

[BigChimp]

What would really help is a converter git diff -> svn diff. Ideally written as a CGI application in fpweb. Then we could host it somewhere (even sourceforge, for example) and convert patches.

AFAIK, GIT does give you unified diffs. Just line endings are not always as expected...

You could try and build on this (on Windows):
fpdiff.cmd

Code: [Select]

@echo off
rem Uses git on windows to create a patch with crlf endings.
rem Requirements:
rem git, linespace converter program (sfk, unix2dos)
rem git core.autocrlf setting is true
rem Tested git core.whitespace trailing-space,space-before-tab,cr-at-eol but had
 no effect
set OUTPUTNAME=your.diff
del %OUTPUTNAME% > NUL 2>1
rem Git diff gives Unix LF line endings;
rem we're on Windows so convert to CRLF
rem Also, use --no-prefix to strip git prefixes from path
rem Redirect errors to bit bucket
rem YOU NEED TO USE CALL to call msysgit git commands:
rem http://osdir.com/ml/version-control.msysgit/2008-04/msg00012.html
call git diff --unified=3 --no-prefix > %OUTPUTNAME% 2>NUL
rem Use swiss file knife to convert, but could
rem also use cygwin unix2dos
sfk lf-to-crlf %OUTPUTNAME%
echo Done, output in %OUTPUTNAME%