I tried to stay away from the flame, but just could not resist, sorry ;-) On Mon, Jan 18, 2010 at 17:47, Florian Klaempfl <[email protected]> wrote: > Well, I don't wonder, you always tell us how great git is but at every > thing I look, it plainly sucks:
> - git svn Well, I agree it is not the best part, I admit, but it sucks only slightly more then plain svn, since that is where most of "git svn"'s limitations come from. > - line feed handling (how can I do it failsafe?) http://stackoverflow.com/questions/170961/whats-the-best-crlf-handling-strategy-with-git In short, set core.safecrlf=true in your gitconfig Most importantly, if you accidentally commit file with wrong line endings, you can fix that rather easily in git, nut with svn, you are screwed. > - merging (how do I merge blocking?) That is meaningless concept in git, see e.g. http://stackoverflow.com/questions/612580/how-does-git-solve-the-merging-problem > - handling of empty directories Yes, that is a wart, but how many empty directories are there in Lazarus repository? > - tortoisegit (ever used tortoisesvn?) Not only used, but was an active contributor: http://www.ohloh.net/p/tortoisesvn/contributors?query=klenin&sort=commits&commit=Update However, I abandoned it in favor of git, and have no regrets ;-) I would recommend using built-in git tools (git gui and gitk) instead or tortoisegit. > Of course, it's all my fault that I don't see the use of the unix script > hackery called git. So you can continue to ignore the concerns and we > will continue to use svn :) Well, script hackery is a good thing to many ;-) I used svn for many projects and still continue to use it for the projects that did not move on (that's three projects now, counting Lazarus). And I liked (and still do), but I found out that there is an even better alternative. Now, let me list some problems I have with svn: 1) It is slow to the point of being unusable. Using TortoiseSVN, "Show log" on the root of Lazarus folder takes anywhere from 15 seconds to 2 minutes. (And yes, log cache is on). Diffing a file to see a change introduced by some commit takes from 30 seconds to 5 minutes (especially for gigantic files like main.pp). Both operations are instantaneous (<1 sec) in git. 2) Update is also slow, but less so and git is merely twice as fast, to 50 times. 3) You can not fix a mistake in history. Once I discovered the power of "git commit --amend" and "git rebase --interactive", I would recommend git based on these two features alone. 4) You can not (easily) commit part of the file. 5) You can not (easily) manage more that one change concurrently, especially if they touch common files. 6) You can not experiment with a feature requiring more than one commit, that is, any non-trivial feature, without a commit access. -- Alexander S. Klenin -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
