---------- Forwarded message ----------

Another important factor about GIT, is that it's an offline version control. Every person has their own repository, so you if the "online" repository goes down, you have the ability to still properly work on things.

If you are working on a code that others works as well, no one hurt each other as long as it offline, and only when it merges to the "online" repository, it's when you merge all of the code.

Another better feature is the way tagging and brunching works. You can mix everything without making a copy of the whole tree all over on each tagging/brunching. and unlike svn, you actually do have differences between the two.

And there are even more features, but the question is if it good for all projects. I don't know the answer, I only know that I moved to git in my last new projects, and it helped me a lot when I was in a need to figure out when I destroy something with my committing, on places where svn would not have any history of that.

Ido

Out of interest, what version of Git are you using? Since v1.5.5 (fairly old already) they defaulted the setting config.autocrlf = True under Windows.

I know, but I don't want some crappy algorithm to guess if linefeed conversion is needed or not, this feels so cvs like *g*

Florian Klaempfl wrote

I know, but I don't want some crappy algorithm to guess if linefeed conversion is needed or not, this feels so cvs like *g*

In that case, all you would need is an editor that supports Unix line endings and not try and convert them to crlf as you edit the file - then everything would work fine, even if autocrlf=False under Windows. So Windows NotePad is NOT an option. ;-)
The 'syn' editor which is based on the original TSynEdit component works perfectly.

Did you know that crlf conversion occurs in SVN as well. Hence the 'eol-style' property in SubVersion. Git tries to auto detect text files and ONLY applies the crlf conversion on those. fpGUI repository should not contain any binary files other than images, and they work correctly even with 'autocrlf=True'. And if a binary file is detected incorrectly as a text file, you can tell git about it using .gitattributes file.

Regards,
- Graeme -

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

ik wrote

Another better feature is the way tagging and brunching works. You can mix everything without making a copy of the whole tree all over on each

Yeah, that is great. Purely to play with git, I checkout out a very old state (v0.4 of around mid 2007) of fpGUI. The v0.4 code was very different and had a very different directory structure. In under 3 seconds the checkout was complete with the new directory layout. I had a few "untracked" files lying around which were compiled .ppu files from the HEAD fpGUI, but that was it. All the old memories came flooding back while I browsed the history version. Then a simple 'git checkout master' and 3 seconds later I was back to todays version of fpGUI. Awesome!! :-)

And there are even more features, but the question is if it good for all projects. I don't know the answer, I only know that I moved to git in my

Very good question. Most of the times when you read about Git, it's all about large projects like Linux Kernel, Wine, Gnome etc... But the nice thing of Git, is that it works just as well for small one-man-band projects. To start using git you only need to know about 5 or so commands (similar to SVN) but then as you get more familiar with it you venture out into new territory and start experimenting with more features.

Bottom line is -- no matter if git is a "distributed version control system" and designed for large projects with a huge hierarchy of developers. Git simply fits my workflow better than SVN ever could. Git makes my life easier!

Regards,
- Graeme -

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

.
.

In this context, any editor which doesn't use LF by default (e.g. for new files) is not an option unless you require Unix users to use an editor supporting CRLF as well or unless you never expect non-Unix users to contribute to the project directly.

Tomas

Well that shouldn't be a problem, because most unix editors I know or use adheres to whatever line ending is in the file. So if a Windows users commits a new file, my system should manage it just fine.

But saying that, by default msysGit uses the Windows line ending style and committing a new file will then automatically be converted to a Unix line ending on the Git repository at SourceForge (they run unix servers there). Line endings for text files are handled correctly under Git by default, so I don't see the issue.

SubVersion has the exact same problem, so it's not like Git is doing something stupid. Git has option for handling this issue and with a default install, the user doesn't need to do anything.

Regards,
- Graeme -

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

On Tue, April 7, 2009 19:55, ik wrote:
.
.

.
.

I certainly don't want to discuss usefulness of git to individual users or projects, but it doesn't seem to be very fit to widely multi-platform projects (yet) because much fewer platforms are supported (directly or indirectly) at the moment than with e.g. SVN.

Tomas

At this point it's not something I need to worry about. fpGUI officially only supports Linux and Windows. Unofficially it supports *BSD and some embedded devices too. Git already runs on more platforms than what fpGUI supports: Windows, Linux, MacOS-X, Solaris etc... So I really don't see the problem.

I wasn't trying to convince every other project to switch to Git. The original thread was simply to notify FPC+fpGUI users that the fpGUI source is now in a different repository. The users that regularly contribute have already switched to Git and have not raised any issues. I did post a message in the fpGUI newsgroup mentioning the move before it was done - nobody raised any concerns.

Regards,
- Graeme -

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

.
.

As I explicitly mentioned, I don't want to question appropriateness of Git for fpGUI (or other particular projects). I only wanted to mention (in the context of notes about great advantages of Git, not in the context of your announcement about fpGUI) that this is a limitation currently and that people deciding on using this or that SCM should take this into their consideration. As a purely hypothetical example (_not_ trying to suggest that you wanted to advertise that!), if FPC decided to switch to Git now, I wouldn't be able to contribute any longer, because no (usable) Git client for OS/2 / eCS exists at the moment as far as I know.

Regards

Tomas

I didn't intend to compare Git to SVN, because I don't know enough about Git (although I share Florian's concerns about "magic" detection of proper file type rather than combination of reasonably conservative and obviously configurable default setting combined with possibility to mark other files as plain text explicitly at the file level). I was only responding to your statement regarding Notepad (which may or may not be relevant in the context of Git's ability to handle this area transparently). Yet again, this probably doesn't have any direct impact to your particular case, it was meant as a general comment.

Tomas

Tomas Hajny wrote

context of notes about great advantages of Git, not in the context of your announcement about fpGUI) that this is a limitation currently and that

Maybe a limitation for projects like FPC yes, but not for fpGUI. OS/2 (even though I loved it in it's day) is not a supported platform of fpGUI. But yes, after reading your last post I understand what you mean.

I wouldn't be able to contribute any longer, because no (usable) Git client for OS/2 / eCS exists at the moment as far as I know.

Ignoring the fact that some exotic platforms like OS/2 doesn't have git support (has anybody actually tried to compile git under OS/2 yet?), learning a new version control system is not that hard. I found CVS more confusing than Git. And from a developer point of view, you only need about 5 commands to do most day-to-day work using git.

Oh Tomas, I only remembered now. There is a native port of Git in the Java language.
It's called 'Java Git' and can be found at: http://www.jgit.org/ I have no idea how far they are, but if it supports up to Git v1.5 features you are good to go on OS/2 or any other platform supporting Java. :-)

Alternatively we can always implement a native Free Pascal Git, which should solve this whole Git + FPC issues. ;-)

Regards,
- Graeme -

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

In our previous episode, Tomas Hajny said:

although I share Florian's concerns about "magic" detection of proper file type rather than combination of reasonably conservative and obviously configurable default setting combined with possibility to mark other files as plain text explicitly at the file level

That also worried me a bit.

Graeme Geldenhuys wrote

On Wed, Apr 8, 2009 at 12:26 PM, Tomas Hajny wrote:

.
.

Apparently yes (I found a reference about on some site in Japan - a lot of Japanese characters, but the important bits were fortunately available in English), but the result is next to useless for a general OS/2 user (i.e. user not running /bin/sh as his primary command line environment). Note that there is a big difference between "having full source codes in language X which may be compilable under certain platform with certain effort and certain version of a compiler for language X" and "having a working binary for the particular platform".

BTW, the point I tried to make was that fewer platforms were supported, not that OS/2 was not supported.

yet?), learning a new version control system is not that hard. I found CVS more confusing than Git. And from a developer point of view, you only need about 5 commands to do most day-to-day work using git.

Well, you do not need to convince me (I simply cannot use it right now anyway for reasons discussed above ;-) ). I'm not questioning the fact how easy it is or not to learn using git and I'm sure there is plenty of other (perfectly valid!) reasons why someone should choose exactly this SCM tool. I do not want to dispute on general Git usefulness nor to provide general comparison to other SCM tools. Ido asked a general question and I tried to provide one particular view which may be overlooked by users of the more "mainstream" platforms.

Please, don't want me to comment on my opinion of a command line tool written in Java and its possible usability...

Alternatively we can always implement a native Free Pascal Git, which should solve this whole Git + FPC issues. ;-)

Oh yes, that is certainly possible, looking forward to that. ;-)

Tomas

Well then you and Florian must have been worried for a very long time. How long has FPC been using SubVersion? ;-) SubVersion also does automatic conversions via the eol-style property. And yes we have all seen what a mess the patches look like if you forget to set that on certain files. I have seen this in my own projects and in Lazarus repository.

Like I mentioned before, you can disable the "magic" detection and leave text files exactly as-is by simply setting autcrlf=False in your .gitconfig file. Then simply make sure you use a half decent editor and not Notepad.

Regards,
- Graeme -

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

In our previous episode, Graeme Geldenhuys said:
[ Charset UTF-8 unsupported, converting... ]

Binary status and textformat automatic conversion based are not the problem.

The problem is that it is based on automatic detection. And you'll see in FPC SVN faqs that setting the mime type is mandatory for this reason, though this can be automated based on extensions.

Like I mentioned before, you can disable the "magic" detection and leave text files exactly as-is by simply setting autcrlf=False in your .gitconfig file. Then simply make sure you use a half decent editor and not Notepad.

That's not the same. Then you still have the mess of crlf mistakes in your history.

Marco van de Voort wrote

That's not the same. Then you still have the mess of crlf mistakes in your history.

Well, if it's fixed in a later revision, then there is no problem. And even worse - if you submit a patch where every single line has changed (due to some screw-up in line ending settings), then you don't deserve to be called a programmer. You (the developer) made the changes you want to submit and alarm bells should have rung when you reviewed your patch before submitting it. It's called common sense or Programming 101.

BTW: In git you can also rewrite the history and probably fix such issues - but don't ask me how, I haven't attempted that yet. :)

Regards,
- Graeme -

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

Oh, maybe at the end I should switch to linux to use git ;) ?

then everything would work fine, even if autocrlf=False under Windows.

Windows uses #10#13 as newline marker, period. A program which cannot handle this well (and svn shows that it is perfectly possible) is simply crap and is not suitable for windows development.

Of course and we use this feature.

Hence the 'eol-style' property in SubVersion. Git tries to auto detect text files and ONLY applies the crlf conversion on those.

And that's what sucks: *auto detection* :)

How can I prevent that I forget this?

Nevertheless, it happened often when we still used cvs. Nobody is perfect, especially when editing, diffing etc. on a samba share and committing from unix which works with svn.

hehe... OK, lets try this one more time...

Florian Klaempfl wrote

> In that case, all you would need is an editor that supports Unix line > endings and not try and convert them to crlf as you edit the file - Oh, maybe at the end I should switch to linux to use git ;) ?

Only if you want a descent OS, but I thought we were only talking about descent editors. ;-)

Windows uses #10#13 as newline marker, period. A program which cannot handle this well (and svn shows that it is perfectly possible) is simply crap and is not suitable for windows development.

And Linux uses #10 as newline marker, period. A program which cannot handle this well (and git shows that it is perfectly possible) is simply crap and is not suitable for Linux development.

So what's you point??? Git *does* handle it correctly - it's perfectly possible.

My reading of the description of `crlf` in gitattributes(5) is: ==========================
`crlf`
^^^^^^

This attribute controls the line-ending convention.

Set::

Setting the `crlf` attribute on a path is meant to mark the path as a "text" file. 'core.autocrlf' conversion takes place without guessing the content type by
inspection.
==========================

Note the "without guessing" part. I got it slightly wrong before - by default git treats all files as text. It only tries to auto detect *binary* files. And if for some reason git does do a good job or you are overly paranoid you can help git out. For example, if you want all *.foo files to be treated as binary files you can have this line in .gitattributes:

*.foo -crlf

This will mean all files with a .foo extension will not have carriage return/line feed translations done. Simply add the .gitattributes into the root directory of your project so it's a tracked file. Now everybody using that project will also get the .gitattributes file.

> 'eol-style' property in SubVersion.  Git tries to auto detect text > files and ONLY applies the crlf conversion on those. And that's what sucks: *auto detection* :)

As i mentioned earlier, I got this slightly wrong. By default git treats all files as text. It only tries to auto detect *binary* files.

By creating the .gitattributes file in the root of the project and adding it to your project.

$ (create your .gitattributes file in root directory of project)
$ git add .gitattributes
$ git commit -m "added gitattributes file to project"

Which means the file is now part of the project. Anybody cloning the project will now automatically get the .gitattributes file and have all the correct settings that the project managers decided on. The same thing is done with the '.gitignore' files in the fpGUI directory. Cloning fpGUI, git will automatically ignore all *.lps;*.ppu;*.o;*.a files when you commit or do a status check. The user doesn't need to do anything on their side.

Regards,
- Graeme -

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

As pascal shows, something proven is often better as some hype ;)

No, if I do it wrong, nothing prevents me to do so, see below. It's the same as with merging: I didn't see any means to avoid the merging of certain changesets to a particular branch as svnmerge does. This fits exactly into my picture of git being a big design failure as a general purpose scm: besides being a posix hack (see also file names: ".gitattributes") it does not help users to avoid mistakes. I admit, as pascal programmer I like fail safe solutions, but you should too ;)

> How can I prevent that I forget this? By creating the .gitattributes file in the root of the project and adding it to your project.

... and when I forget to add a file to .gitattributes, nothing helps me. Our svn server is configured to prevent adding of files without proper mime property settings.

Florian Klaempfl wrote

As pascal shows, something proven is often better as some hype ;)

Good answer. :)

exactly into my picture of git being a big design failure as a general purpose scm: besides being a posix hack (see also file names: ".gitattributes") it does not help users to avoid mistakes. I admit, as

Well with all due respect, Git was designed in the beginning to solve a problem of one specific project - the Linux Kernel. So don't you think they were allowed to have Linux specific features in it's design.

Even so, now that more people start liking the idea of Git (you excluded obviously <wink>), it is being amended to play nicer on other platforms as well. So far they are going a great job. BTW: I understand FPC was Windows only in the beginning. ;-)

What's wrong with the file names? And if you tell me it's because it doesn't have an extension well then... Linux like most other OS's (excluding Windows) can detect a file type very easily. It doesn't need to use the ridiculous 3 character extension to tell it what file type it is or if it may or may not be executable. I see this as a strength in *nix based OS's, not a weakness. As for the prefixed dot (.), well that is simple and ellegant. You can create a file or folder and make it hidden all in one swoop - no need to fiddle with file attributes. Brilliant. :-)

So you had to fiddle with the SubVersion server settings BEFORE things get handled correctly. What if you forgot? ;-)

With Git's '.gitattributes' and '.gitignore' files you can let those "server settings" go with the repository when it's cloned. Just like SubVersion, you ideal "tweak" settings need to be done before hand and also only once.

And if there is any more doubts about line ending conversion. Git can do sanity checks for you and warn about potential conversion issues. Welcome to the "core.safecrlf" setting....

================
If core.safecrlf is set to "true" or "warn", git verifies if the conversion is reversible for the current setting of core.autocrlf. For "true", git rejects irreversible conversions; for "warn", git only prints a warning but accepts an irreversible conversion.
==================

But I do think you have a point. Using standard mime types built into git (and extendible by repository maintainers via config file) would be a valuable addition to git. Simply to please that last few folk that can't decide if they like or hate git. :)

Regards,
- Graeme -

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

Graeme Geldenhuys wrote

On Wed, Apr 8, 2009 at 3:41 PM, Florian Klaempfl wrote:

.
.

platforms as well. So far they are going a great job. BTW: I understand FPC was Windows only in the beginning. ;-)

.
.

No, DOS. ;-)

Tomas

Windows support was very late in FPC: afaik it was added around 1998.

. . No, DOS. ;-)

Also partly wrong ;) For myself, I started FPC to have a pascal compiler on linux and 32 bit dos extenders for my chess programs. However, I realized soon, that I could not develop on linux without TP which didn't run on DOS emu at these times so I dropped work on a linux version and concentrated on the DOS version. A few months later I added OS/2 support. OS/2 was quite popular in Germany during 1993-1995.

But the point is: I tried to design FPC in a way which makes it cross platform and avoids platform specific stuff. At least as far as I understood things at this time ;)