Hi Everybody,

A while back I setup a private Git mirror of the Lazarus SubVersion (trunk only) repository. This was for my personal use. Since then I thought others might enjoy a Git mirror as well. Seeing that our company has limited internet bandwidth I decided to move the mirror repository to a more public place. The Git mirror is hosted on GitHub at the following URL and is sync'ed with Lazarus SubVersion trunk every 15 minutes.

git://github.com/graemeg/lazarus.git

The Lazarus Trunk (exact duplicate) is mirrored in the 'upstream' branch which I'll explain shortly.

I just completed a repository clone from GitHub to make sure everything is working properly. The whole history of Lazarus (trunk) gets downloaded by default and is just 57MB!! With the testing I done locally, that is even less than SubVersion's 'svn co ..../trunk' which only gets ONE revision!

To clone Lazarus Git repository with full history
-------------------------------------------------

   $ git clone git://github.com/graemeg/lazarus.git

...this will download 57MB of data and unpack to
around 144MB on your hard drive. This has the whole history of Lazarus. A checkout via SubVersion of only the trunk revision is over 320MB - more than double what Git is with full history.

To clone only partial history of Lazarus Git repository ------------------------------------------------------- Lets say we want only the history since the last 10 commits.

   $ git clone --depth 10 git://github.com/graemeg/lazarus.git

...this will download 14MB of data and unpack to around 96MB on your hard drive. You will now only have the last 10 commits as your history.

Considering that the Lazarus source code alone is 82MB in size (excluding all the hidden .svn directories), Git gives you a pretty sweet deal! ;-)

About that 'upstream' branch
----------------------------
Because I'm mirroring the Lazarus svn repository (GitHub considers it as a fork), I want to make sure I always have a pristine copy of what is in SubVersion. That's what the 'origin/upstream' branch is all about. The default 'master' branch is my playground and might contain my customized version of Lazarus (something like my private fork though it will probably never get used or updated much).

So for you to work with the original upstream version of Lazarus (the one that lives in SVN trunk) you need to do the following:

     $ git checkout -b work origin/upstream

...this creates a new branch called 'work' which tracks the original SVN trunk branch and also allows you to create your own custom changes or bug fixes. That's the one MOST users would want!

Now to keep up to date with what's happening in SVN trunk, git 'upstream' branch, you simply need to run the following git command to update your local repository.

    $ git pull

The nice thing about Git's merge is that if you created a patch and it was later included in Lazarus's SVN trunk (assuming it's applied verbatim), it will filter through to 'upstream' and then filter into your 'work' branch. Git is supposedly smart enough to realize that it's the same change you have locally and keep things nice and tidy. Else you can force a merge and trash your local changes.

If you want to make local changes like bug fixes (after all, we do love to help the core developers out) and you want to submit those patches to the mailing list or to Mantis, you would have the following workflow.

    $ git pull                (make sure we are up to date with SVN)
    $ (edit..edit..edit)      (create a bug fix)
    $ git add <filename>      (stage the file for next commit)
    $ git commit -m 'describe what I changed'
    $ git format-patch HEAD^..HEAD
or replace the last line with
    $ git log -1              (to see the last commit message and SHA1)
    $ git format-patch -1 <commit_SHA1>

...You will now have a numbered patch file which you can attach to an email or submit via Mantis. If you specified a larger revision range you will have multiple patch files in order which you can submit to Mantis.

For more info on any git commands simply type:

    $ git help <command>
eg:
    $ git help format-patch
    $ git help commit
    $ git help add

Or go to the Git website where there are plenty of tutorials, downloadable PDF books etc..

http://git-scm.com/

Hope you enjoy! :-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Windows users?

I am downloading TortoiseGit (http://code.google.com/p/tortoisegit/) as we speak, and will try to get the latest 10 revisions :-)

Regards,
-Reenen

git://github.com/graemeg/lazarus.git

And for those Windows users still thinking they are left out. There is a native Windows port of Git called msysGit available on SourceForge.

http://code.google.com/p/msysgit/

I've tested it and it works perfectly on a Windows 2000 system. I also can't see any performance difference compared to the Linux version of git. They both work the same for me, so you don't need the old Cygwin version anymore.

As far as I have heard, the TortoiseGit also has 95% of the features that TortoiseSVN has, so that should be pretty usable as well. I don't use such GUI tools for any version control systems, so can't really answer any other questions regarding them.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Reenen Laurie wrote

Windows users? I am downloading TortoiseGit (http://code.google.com/p/tortoisegit/) as we speak, and will try to get the latest 10 revisions :-)

See my previous post. Windows is well supported now, so you shouldn't have any issues. There is also a Git version for MacOS, but I don't know anything more about it.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

2009/4/9 Graeme Geldenhuys :

tortoisegit needs msysgit to be installed.

quoting from the msysgit home page:

"Once you installed msysGit, git will be compiled and the repository will be fetched, so you are good to go. Play with git a little, and you will find plenty of stuff that is not quite optimal."

it's a bit hard to judge how well it works. i'll have to try it out when i boot into windows again (in a couple of months, probably ;)

henry

Henry Vermaak wrote

tortoisegit needs msysgit to be installed.

I see no problem... why double the work of implementing two native versions of Git.

when i boot into windows again (in a couple of months, probably ;)

:-) I feel the same. I loaded my Windows VM this week, so my quota is done for the next few months.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

I have successfully cloned the repo with msysgit.
Everything seems to work at the first glance.
Will play with it more and report the results.

Hm, apparently sync is not working.

Alexander Klenin wrote

Hm, apparently sync is not working.

Oops, I forgot to make the update script executable on the new server. :-) It should be sync'ed now.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Something I forgot to mention in my first post....

BTW:
I'll start a wiki page describing an example workflow and Git usage with the Lazarus mirror.

This will update your local repository, but it will not automatically update your local branch. Remember we created a 'work' branch which is local to our repository. So to update our local 'work' branch with the 'upstream' branch we use the rebase command.

     $ git rebase origin/upstream

The 'git pull' already fetched the changes from GitHub. the 'git rebase' simply replays all new commits from the 'upstream' branch into our 'work' branch.

This is quite nice, because your 'work' is only updated when you say so. So if you find a revision that is nice and stable for you, you can continue pull in all new change from GitHub, but your local branch still stays nice and stable. You can then cherry-pick and new patches you want to merge with your branch (for example testing a specific fix), or rebase your branch with the last code from 'upsteam' (which is svn trunk).

So in summary, I can keep my repository (upstream branch) up to date with svn trunk, but I don't necessarily have to immediately use that new revision. I can review the changes first. This is how I mostly work with Lazarus. When I find a stable revision in svn trunk, I stick with it for a while (after all, I write commercial software with Lazarus IDE, so I must always be able to do my work).

And if I get a request to retest a bug report with the latest lazarus from svn trunk. I can quickly create a new temporary local branch which is in sync with 'upstream', test the new feature and report back to Mantis. Then switch back to my trusty stable 'work' branch and delete the temporary branch I just created.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Hi,

I created a wiki page documenting the steps on using the Git mirror of Lazarus SubVersion repository.

http://wiki.lazarus.freepascal.org/git_mirrors

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/