If more features equals better ...

Moth fly into the light, not because it is better, but because it is shiny. And a sledge hammer is not the best tool to drive a nail into your wall.

Look around. I have seen many git repositories (svn probably too), where the (sole) committer uses git in a way, that cvs would allow to do more. How is git better for them?

This may still leave git the better choice for many (maybe even a majority). But 99% ?

Also one should make such decisions based on what is needed. Not what others do.

Moths fly into flame,
not because it is better,
but because it shines.

And a sledge hammer is not the best tool to drive a nail into your wall.

That one's more difficult, since it lacks allusion to a season :-)

A practical problem with Git, as I've said already, is that it's got much less proven portability. Also since it was originally written for Linux developers, there might be an irrational revulsion on the part of closed-source programmers and administrators. Sorry Tony, but those also apply to Fossil.

The bottom line, however, is that when one is looking for a public (and preferably free) hosting service one is constrained to looking at what's available, which in practice means Subversion and Git- even if they're overkill in many cases.

Losing Google Code is unfortunate, particularly after losing Berlios.

The obvious alternative for a small project would be to run an svn server as a parasite on a router: something like svnserve (possibly with an SSH wrapper) is pretty small. There's obviously the risk that the server will be lost, but if collaborative users are persuaded to pull and republish the entire repository (svnsync or whatever) that can be mitigated.

The downside of that is the number of "script kiddies" out there who are quick to try to abuse anything that looks like a login port. A few months ago I put an SSH login on a number of outward-facing servers, and within a few hours our Internet traffic had gone up substantially: there were no successful penetrations, just a constant drone of attempts which in aggregate came close to exceeding our office-hours quota.

Hello Mark Morgan,

I wasn't going to reply because I've had enough fruitless debates in these mailing lists. But here I go again - I just can't help myself - especially if I see false statement being thrown around as if they are fact.

Reading the replies I can clearly see that neither of you have ever used Git for actual work. I'm not talking about just installing it and not doing anything with it - that's NOT using a product, so you can't review it based on that.

> Look around. I have seen many git repositories (svn probably too), where > the (sole) committer uses git in a way, that cvs would allow to do more. > How is git better for them?

Your statement is so ridiculous I had to laugh out loud. Git is magnitudes better that CVS and SubVersion combined. And yes it is extremely useful even for a sole developer. I even use git (because it is so damn quick and cheap to start a repo - see below) while writing throw-away code, or fixing sample code for support reasons. Local branches to jump onto various tasks - another WOW.

If you haven't actually used git, then please stop spreading FUD. You are not helping anybody.

> Also one should make such decisions based on what is needed. Not what > others do.

if you actually tried git, you would soon realise it is a vital tool in the developers toolbox. I regard Git just as important as a good programmer editor or IDE. Yes, that important!

A practical problem with Git, as I've said already, is that it's got much less proven portability.

What the f**k does that mean? Git not portable? Under what rock have you been living for the last 6 years?? Git has been ported to Linux, FreeBSD, OpenBSD, Solaris, OS/2, Windows, Haiku, AIX, Mac OSX and gods knows what else. There is even a fully functional and up-to-date Java implementation (used by Eclipse developers) of Git. How the hell is all that not portable?

The Git you are talking about is from around 2006/7 - a lifetime ago if you see how fast git is being developed.

I use Git equal amounts under Linux, FreeBSD and Windows in my daily work. I see absolutely NO difference in usage and performance.

Losing Google Code is unfortunate, particularly after losing Berlios.

Yes, we agree on something. Gitorious will be lost soon too. It is sad seeing these services disappear and taking lots of open source software with them.

But another huge plus point of Git. If just one person cloned any of those public Git repos, they can fully recreate such a repo on another service because Git always has the full repository history. With CVS, SubVersion you loose a lot of information because you only have the last single commit you checked out.

The obvious alternative for a small project would be to run an svn server as a parasite on a router: something like svnserve (possibly with

Again, a clear indication that you have NEVER used Git before. Git is infinitely faster and easier to setup.

Start a new Git repository for an existing code base

            $ cd /path/to/my/codebase
            $ git init      (1)
            $ git add .     (2)
            $ git commit    (3)
      1. Create a /path/to/my/codebase/.git directory.
      2. Add all existing files to the index.
      3. Record the pristine state as the first commit in the history.

Congratulations, you have a fully working and 100% setup Git repository! No server required, no "parasite service/daemon" required etc.

I have helped numerous individuals and companies switch from SubVersion to Git. To be honest, all of them were sceptical about the move, but all heard so many good things about Git. I can also say that not a single one of them were disappointed afterwards. After a week of initial getting used to a distributed system, they all really appreciated the performance, features and flexibility of what Git has to offer. NOBODY I know has ever considered going back to SubVersion after using Git. That has to speak volumes.

Regards,
Graeme

Graeme Geldenhuys wrote

NOBODY I know has ever considered going back to SubVersion after using Git.

Good to know that upper case NOBODY includes me :)

Graeme Geldenhuys wrote

Hello Mark Morgan,

If you /don't/ mind, the name is Mark Morgan Lloyd. The original Morgan Lloyd (strictly, Morgan Llwyd) was a churchman of considerable renown, and at some point my family adopted his name which persists to the current generation.

As far as the Git advocacy goes: frankly, old chap, I don't give a damn. My major criterion is the jurisdiction and laws (and de-facto regulations and conventions) under which a service operates, I'd prefer to use Subversion since that's what I'm marginally familiar with, but I've got nothing in particular against Git except that if you're typical of its users then perhaps I ought to have.

Thanks for the heads-up.

You are very close there to quoting me out of context, which is something that I'm not prepared to tolerate. I agree that in-context, I could probably better have written

"The obvious alternative for a small project would be to run an svn (or git etc.) server as a parasite on a router: something like svnserve (or equivalent, possibly with an SSH wrapper) is pretty small. There's obviously the risk that the server will be lost, but if collaborative users are persuaded to pull and republish the entire repository (svnsync or whatever) that can be mitigated."

HOWEVER, the thing that I was trying to emphasise was the next paragraph, where I warned that from recent experience exposing SSH will result in undesired traffic, and even if Subversion (or Git, or anything else) has as good implicit security as SSH if it's considered to offer a potential entry point for hackers then /it/ /will/ be attacked.

If there are constant hacker attacks it will inflate the amount of data that passes through the routers (DSL, leased line or whatever) even if it's rejected by the firewalls, and this might attract ISP charges which are obviously highly undesirable. This could possibly be avoided by using an unfamiliar port, but at best this is "security by obscurity" and it has the disadvantage that published data probably won't be noticed by people like archive.org or Google.

Here is a simple introduction to git (as well as Linux, Python, Vim): http://levinux.com

I'd like to do something similar for FPC & Lazarus (as mentioned before in these forums).

It is sad to see the tone of these Git vs SubVersion messages...

I know git and I can use it but I cannot get used to it. Besides a lot of other things which annoy me, it still misses good gui tools for me, especially on non-windows. TortoiseGit on Windows is ok, but something like CommitMonitor which I use for fast code reviewing is afaik not avaiblable for git. And yes, I am a gui guy and I refuse to type lengthy command line message which I've always to look up in some self made cheat sheet or in the man pages.

http://levinux.com

Bad for them that I am not enabling JavaScript (or whatever) for some random site :)

Let's put it this way: I don't think that anybody is advocating Subversion in a way that would raise eyebrows if a potential employer came across this thread via Google.

My position is that I'd tolerate almost anything- cvs, rcs- provided that the political and contractual terms were acceptable. I suppose that for small and slow-moving projects a hybrid approach would be possible: apply patches to a local VCS, and then dump that to an ISP's HTTP or FTP server nightly.

I think the main FPC developers need to realize that sooner or later they are allow going to retire from FPC development and move onto other things, or just retire form working life, or finally to the great happy retirement home in the sky, and a new generation will have to take over FPC development. They have to plan and workout a succession, and that succession will have to involve a new generation of programmers who learned different ways of working, and that more or less involves Git and a whole lot of other tools.

Somehow all this indifference to Git bothers me because it seems they are ignoring the greater realities of life. If a new generation are going to get involved with FPC and Lazarus development, and the main developers are really concerned with all the time and effort they put into this great product not going to waste when they retire then they ought to reconsider the indifference or aversion to Git. This is what the aversion or indifference to Git signifies me. It doesn't mean that I don't think they don't have any plans for how the project will be continued in the long term future, but there seems to an indifference in the appeal the working culture has for newer generation. They need foster a passion and a commitment (fanboy fanaticism may be the right word) to Lazarus and FPC in a new generation.

If you think I am such a Git fanboy I am not. For personal projects I am beginning to find Git rather cumbersone as it doesn't have project management, ticketing, patch reviewal and a host of other stuff built in. I am beginning to consider Fossil, yes, the same Fossil that is being mocked in this thread as an alternative because it comes with batteries included.

Now Florian, considering your preference for GUI tools, won't the development of cross platform Git GUI surpassing Tortoise Git, Github and Atlassian's tools, SmartGit and whatever be the best advert for Lazarus and FPC? There would such a major flow of patches coming in that you would have to stop coding actively and review the patches going in like Linus does. You could have your cake and eat it too. :). I think such a tool with documentation on how it was built would be the best advert for Lazarus and FreePascal. Graeme?

Luckily enough, this is an automatism. As soon as somebody pops up and does e.g. repository maintainance, fixes branch merging etc. and volounteers to work on switching the whole FPC infrastructure to git, this will happen. Since this is a lot of really tedious work, it will be probably take another couple of decades especially as anybody really used to git can use it already flawlessly with git-svn. Ever wondered how Jonas can commit hundreds of changesets within a few minutes ;)?

Now Florian, considering your preference for GUI tools, won't the development of cross platform Git GUI surpassing Tortoise Git, Github and Atlassian's tools, SmartGit and whatever be the best advert for Lazarus and FPC?

In a world with unlimited resources and time? Maybe.

There would such a major flow of patches coming in that you would have to stop coding actively and review the patches going in like Linus does.

For sure not my aim, actually, if I had only to review patches, I would quit to work on FPC or whatever.

El 15/03/15 a les 11:10, Graeme Geldenhuys ha escrit:

[snipped lengthy part about git features]

I don't dispute that, I even tentatively migrated my googlecode projects to github (though I might reconsider and use bitbucket instead), but the same can be said about mercurial. I still cannot wrap my head around git, though I had no difficulty picking up mercurial (at least for basic functionality).
I don't really see the advantages of using git instead of mercurial (other than going with the flow, but then I would stop using pascal if that was my main motivation).

Bye

... not to mention that I am using also git-svn sometimes as a "patch manager" for FPC development (drawback: around 60 private branches with some nice stuff, wouldn't happen with svn ;)). Nevertheless I see no point in using git as FPC's main repository so far.

In our previous episode, vfclists . said:

Yeah, and I have interesting property on the moon to sell. I've a feeling you are the perfect guy for it :-)

Arguments on "change your infrastructure like this and the hordes will come" are considered with very big scepticism. Call it Voort's law if you will.

Since somehow those hordes never materialize.

Hello Paul,

Paul Breneman wrote

Here is a simple introduction to git (as well as Linux, Python, Vim): http://levinux.com

Brilliant idea using a single web page as a slideshow. :)

Regards,
Graeme

Hello Mark,

Mark Morgan Lloyd wrote

for small and slow-moving projects a hybrid approach would be possible:

Sure it would be possible, but definitely not the most efficient way of working. In this day and age time is money - more than ever before. I simply find Git a lot more efficient for my needs than anything I have used before (Zip files, CSV, Team Coherence, SourceSafe, Perforce, SubVersion etc). If someone is too afraid or closed minded to try something new that could be very beneficial to them, then their loss I guess.

Regards,
Graeme

Hi,

vfclists . wrote

I think such a tool with documentation on how it was built would be the best advert for Lazarus and FreePascal. Graeme?

I've tried ever GUI tool under the sun for Git. They all have there faults. In most cases they often get confused about the actual state of the repo, are slow as hell, or simply lag behind the actual Git cli tool.

Also having to learn different GUI tools on each platform I use is damn annoying too.

So with all the above taken into account, that is why I prefer to do all my git work from the command line. I must confess I use 'git gui' and 'gitk' very often too. Ignore the fact that those Tcl/Tk apps will not win any beauty contest, but they sure as hell are very efficient, functional and consistent across all platforms that Git supports. In fact they have many hidden command line parameters too, which change their functionality, making them more useful. Other GUI front-ends just can't keep up with Git's development pace. So now I only have one set of tools to learn and can happily jump between platforms and not miss a beat. The standard Git under Windows even have shell integration for those die-hard GUI fans.

So no, I don't condone yet another feature limiting Git frontend - we already have way to many out there for my liking.

Regards,
Graeme

Hello Florian,

Florian Klämpfl wrote

with git-svn

'git svn' is super useful - I use it often. It is merely a stop-gap though. It limits a git repo (features) a lot. But like I said, it is still useful.

Regards,
Graeme

Very much agreed. But most people with a conventional ISP have a few hundred Mb webspace gratis, while getting a VCS installed at a colocation facility would cost.

[Remaining advocacy deleted.]

Users that want to be developers for FPC should first and foremost love the language. What backend we use to manage the code should not be important then. There are even successful projects out there that still use CVS, so don't come with "if it's not Git then no one will come".

Regards,
Sven

My reply is not so much about Git being superior to SVN, its more about how to broaden the appeal of Lazarus and FreePascal to a new generation who will carry it forward into the future. I know that FreePascal developers are grizzled veterans who have seen lots of new fads come and go, but how do you draw in a new generation of users to a good product, when there are so many competing (and mostly inferior) alternatives around?

The 'real men use the DOS/Git command line', 'real men use SVN', 'real men don't drink Diet Coke', 'real men use Emacs' image doesn't help. It is more about image rather than substance.

I am not saying that switching from Git to SVN will popularize FreePascal and Lazarus, but choice of version control aside, what can broaden the appeal of FreePascal and Lazarus to a new generation. It probably warrants a different thread.

I know this isn't the style of FreePascal and Lazarus's developers who are a group of dedicated volunteers, but Pascal is still quite popular in Europe, and it may be time to seek some funds from some European funding agency and give FreePascal and Lazarus developers, together with the whole Pascal ecosystem the major push it definitely deserves.

Reading the replies I can clearly see that neither of you have ever used Git for actual work.

I have, and I do. That said, only for maybe 6 to 9 month by now, and in that time I might well only have scratched the surface of it, and yet much to discover.

But never mind how well I know it, that was never the point. I did at *no* time say that git was not good, or could not be useful.

I said that, it is not always the best choice, for that: read on below:

That has nothing to do with what I wrote. And I never said that this was not the case. Yes it *can* be very useful for a single developer.

But that does not change, that there are developers who store their projects in GIT, but who do not use the such a
developer it can be said, that even CVS has more feature, than the set of features they use in GIT.
This is one case, where GIT was clearly not the best choice. (Assuming they had choice)

It is not about what GIT can do, but what a developer makes out of it. And also what a developer actually wants or needs.

then please stop spreading FUD

Read what I wrote, before falsely accusing me of spreading FUD.

if you actually tried git, you would soon realise it is a vital tool

I tried it, not only did I try it, I use it for some projects. I still stand by the statement that I made.

I regard Git just as important as a good programmer editor or IDE. Yes, that important!

I agree, yet there are many IDEs, and for different tasks different IDE are better suited

Reading the replies I can clearly see that neither of you have ever used Git for actual work.

I have, and I do. That said, only for maybe 6 to 9 month by now, and in that time I might well only have scratched the surface of it, and yet much to discover.

But never mind how well I know it, that was never the point. I did at *no* time say that git was not good, or could not be useful.

I said that, it is not always the best choice, for that: read on below:

That has nothing to do with what I wrote. And I never said that this was not the case. Yes it *can* be very useful for a single developer.

But that does not change, that there are developers who store their projects in GIT, but who do not use the such a
developer it can be said, that even CVS has more feature, than the set of features they use in GIT.
This is one case, where GIT was clearly not the best choice. (Assuming they had choice)

It is not about what GIT can do, but what a developer makes out of it. And also what a developer actually wants or needs.

then please stop spreading FUD

Read what I wrote, before falsely accusing me of spreading FUD.

if you actually tried git, you would soon realise it is a vital tool

I tried it, not only did I try it, I use it for some projects. I still stand by the statement that I made.

I regard Git just as important as a good programmer editor or IDE. Yes, that important!

I agree, yet there are many IDEs, and for different tasks different IDE are better suited

Sorry, I'll try to put both links together next time: http://mikelev.in/ux/

I forget that in my reply:

That is what some people do (and what I pointed out): install, but not really use.

I did *not* judge GIT on that.

I did judge your statement on it, that

/As 99% of developers would tell you, Git is simply// the better product./

1) How would those none users even judge that, what value would there statement have.
2) Should they really be told that GIT was best for them?

If they do not want/care to use all the features. If for example all they want is an online backup, with access to all previous backups (revisions): Should I tell them GIT is the best product for that task?

I am willing to believe that 99% of the developers you know / you have asked say that (and even that, when they said it, it was correct in the situation.)
But "the developers you know / you have asked" are not a random selected group, they are not representative of *all* developers.

If you state the above, without clarification of what group of developers, in oher word, if you refer to *all* developers then I disagree.

So I am convinced that:
- either a lesser percentage does say so
- they are giving bad advice (telling someone to use git, who would be better off without)

Hello Martin,

There is no rule that says you must use all feature of Git, otherwise it is waisted or not the best choice. Like I tell everybody else. To get started with Git you need to know about 4-6 commands (just like svn) and that will allow you to do most day-to-day development work with it. Perfect, and nothing wrong with that. You now have a reliable and stable source code management system will a full backup of all your project changes. What workflow you use is irrelevant.

Then as time goes by and your confidence with Git grows, then start experimenting with other commands and features. Learn and use git at your own place.

What I like about it is that it is extremely quick to get a repo started (unlike say SubVersion, Team Coherence, Perforce, SourceSafe etc). No service/daemon required, no remote server needed. Just a directory where you can run 'git init' and you are set to go.

Regards,
Graeme

Hello Martin,

Martin Frb wrote

I did judge your statement on it, that > /As 99% of developers would tell you, Git is simply// the better product./

My apologies if there has been some confusion. Probably down to a language barrier issue.

In the context the usage of "99%" wasn't meant a specific number. It's like saying "there are a 101 ways to skin a cat". You are not specifically saying there is only a 101 ways (not 100, not 102). You also don't actually want to remove the skin off a cat. :) [what a terrible saying - I love cats] It is a generalised statement meaning "a lot" or "the majority" agree there are many ways to accomplish something.

So to rephrase my quoted statement I could have said

"As the majority of developers would tell you, Git is simply the better product at this stage".

If you want facts, then do a Google search. See the exponential growth of projects migrating from SubVersion (or other systems) to Git. Qt, KDE, Linux Kernel etc - they are massive projects and must have had very good reason to move to Git.

Also observe the amount of new code storage services popping up - most based around Git repositories. I personally have not observed recent code repository services appearing on the internet boasting (or even supporting) SubVersion. Surely that has to mean something.

Obviously you as a developer or company have to make your own choice - evaluate the pros and cons of each code management system. How difficult it would be to migrate and see what solution would benefit you in the short and long term.

Regards,
Graeme

Hello Luca,

Luca Olivetti wrote

but the same can be said about mercurial. I still cannot wrap my head around git, though I had no difficulty picking up mercurial (at least for basic functionality).

Agreed, Git and Mercurial are very similar (at some point). I haven't found or observed any real difficulty in familiarising oneself with either product. I can say what I don't like about Mercurial. It is a plugin based system (at least that is how it was when I last looked at it - I stopped following Mercurial development). So after you installed the base, then you need to start adding in the plugins to get real features. Your plugins might not be the same as somebody else's - so you can't trade solutions (commands) easily between developers like you can with Git. Git was just an easier setup for me. I also don't like the incremental version numbering of Mercurial - especially considering that it is a distributed system, so such version numbers really have NO meaning in a distributed system. For the long term prospects, Git just seems to have more momentum.

But again, use whatever fits you best. I did deep evaluations of many systems, then made my choice. So far, I'm very happy with my choice and outcome.

Regards,
Graeme

What it means is that more hosting services find it convenient to offer Git than find it convenient to offer Subversion, you've already claimed that it's easier to administer. In other words, the end-user who's just looking for somewhere to store his code simply doesn't get a choice.

A better metric might be finding somebody who offers a selection of VCS protocols (possibly with a common backend- I believe such things exist?) and then looking at the relative use for checkouts etc.

However as I've said already, the most important concern for me is not the protocol so much as the jurisdiction.

Hello Mark,

Mark Morgan Lloyd wrote

A better metric might be finding somebody who offers a selection of VCS protocols (possibly with a common backend- I believe such things exist?) and then looking at the relative use for checkouts etc.

You can start by looking at the following Wikipedia page

http://en.wikipedia.org/wiki/Comparison_of_source_code_software_hosting_facilities

See the "Popularity" section. GitHub sits and 19.8mil projects. Second place is SourceForge at a mere 324k. Stats are published numbers directly from each service provider. That is quite impressive, I never realised GitHub was that big - I somehow thought SourceForge would be tops. I also didn't realise Google Code being so popular (250k projects).

Regards,
Graeme

I don't know why do you keep saying that. Do you know you can do the same thing with svn? It's a single command - "svnadmin create" followed by a directory name. You don't need any daemons and remote servers - you can immediately checkout from this local directory.

Nikolay

Graeme Geldenhuys wrote

But again, use whatever fits you best. I did deep evaluations of many systems, then made my choice. So far, I'm very happy with my choice and outcome.

Yes, we *know*. You have made us well aware of this fact. :)

Nikolay

In our previous episode, Graeme Geldenhuys said:

If you look on the github referenced page, its repositories, not projects. The translation to projects is wikipedias own.

The fact that github+gitlab projects >people and by others the other way around should ring a bell.

I get the feeling these stats are meaningless because github has a large excess of personal repositories that skews stats, while sf was more collaboration oriented.

Also it's still based on what's being offered, not on what users would adopt if it were available.

Now it might be that git is inherently more secure than svn etc.- I don't mean more resilient when it comes to rolling back mischief, I mean *SECURE* as in "there's no buffer overflows or certificate weaknesses". Obviously that sort of thing would make it more attractive from the POV of somebody building a business around it, but so far I see nobody arguing that point and fewer people providing uncontestable evidence :-)

Graeme Geldenhuys wrote

If you want facts, then do a Google search. See the exponential growth of projects migrating from SubVersion (or other systems) to Git. Qt, KDE, Linux Kernel etc - they are massive projects and must have had very good reason to move to Git.

The Linux developers moved because they were thrown off Bitkeeper after being accused of reverse-engineering it.

I'm aware of the fact that there's something about managing directories (or possibly branches/tags) in Subversion that's considered broken, and I believe that when Torvalds hurriedly designed Git he took pains to fix that particular flaw. If one of the FPC maintainers can remember the details perhaps they'd explain them, after all /somebody/ has to give Graeme something concrete on which to build his argument :-)

On 16 March 2015 at 11:50, Mark Morgan Lloyd <

I think Graeme's statement should be "99% of developers who have good working experience with BOTH consider Git to be better", but there have there been any good surveys supporting that conclusion?

Again: Not what I wrote.

In fact I wrote: I (myself, as an example) am using GIT, yet I am sure that it still has much for me to discover.
But just because in my case that is still making at a good choice (in specific cases, the best within the range of choices I know), does not mean that this is the same in every case.

As for what you wrote.

Yes there is no such rule.
But the absence of such a rule, does *not* mean the absence of such cases.

Not every case where GIT is not fully used, is a waste. But such case do exist none the less.

Hello Mark,

Mark Morgan Lloyd wrote

details perhaps they'd explain them, after all /somebody/ has to give Graeme something concrete on which to build his argument :-)

hehehe... Just watch Linus's Google Tech Talk on YouTube. ;-)

I can also add that SubVersion has *no* concept of Tags. To SubVersion there is no difference between a Tag and a Branch. Why do I say that? Simply because you can create a Tag in the repository, and then start adding commits to it.... just mind boggling! :) Why did they even bother.

Regards,
Graeme

Hello Frank,

vfclists . wrote

have there been any good surveys supporting that conclusion?

Yes, mine. :-P

G.

Graeme Geldenhuys wrote

"As the majority of developers would tell you, Git is simply the better product at this stage".

That I can live with.

There is a 2nd potential point of confusion to it.

"better product", simply means: Compared to others it scores better on more use cases.

It does no mean (at least not to me), that it is better for *all* (or very high percentage [1]) use cases.

I did myself mix that up in my previous reply.

----
[1]
This in not to say, it could not be a high percentage, it just says that the phrase does not necessarily mean this.

For example (assuming you use a provider, and do not have to set up the server). The learning curve for an absolute newly is higher for GIT than far SVN.

Different people learn in different ways. There will be a fair share of people for whom taking their first steps into using a repository is better done with a simpler system. (Just for the learning, but it still is a valid use case)

I agree. In any reasonable vocabulary, a tag would represent a particular revision number relative to a branch.

Hello Martin,

Martin Frb wrote

"better product", simply means: Compared to others it scores better on more use cases.

Agreed. :-)

Different people learn in different ways. There will be a fair share of people for whom taking their first steps into using a repository is better done with a simpler system.

I fully understand that. I think the biggest resistance to migrating to git is the "distributed system" principle. That scares people. That is why I introduced the developers, at my previous employment, to git by simplifying things. I let them use a client/server workflow model. That seem to have helped them a lot, and get over that fear they had.

Regards,
Graeme

Graeme Geldenhuys wrote

I can also add that SubVersion has *no* concept of Tags. To SubVersion there is no difference between a Tag and a Branch. Why do I say that? Simply because you can create a Tag in the repository, and then start adding commits to it.... just mind boggling! :) Why did they even bother.

You can add a pre-commit hook that disallows changes to the tags directory:

http://stackoverflow.com/questions/464384/svn-pre-commit-hook-for-avoiding-changes-to-tags-subdirectories

Nikolay

Actually there are other things:

Local commits (commit, without push) can be a huge advantage. But the act that you need twice the commands to get your commit to the server can also be a turn off (Command line you can use a script / but with a GUI...).

Same for update.
"svn up" is roughly equal to: stash, fetch and rebase (pull?), stash pop. This is, if I want to update, and just be left with any merge conflicts in by local changes.
Sure Git offers me tons of choices here, and sometimes they are useful. But if I just want the equivalent of "svn up", then git is more work.

Hello Martin,

Martin Frb wrote

Local commits (commit, without push) can be a huge advantage.

Ah yes, but they loved the idea shortly afterwards. Then weeks later when I mentioned the rebase command to neaten up local commits before you make it public - that was another hour of explanation and examples on a whiteboard. :-) Strangely they found out by themselves (to my surprise) about the 'rebase --onto' command and now use that a lot.

"svn up" is roughly equal to: stash, fetch and rebase (pull?), stash pop.

A simple git alias can do that for you all in one command. ;-) I've attached some of my most used alias commands. You might find some of them useful. Simply copy them into your $HOME/.gitconfig file.

pull = fetch + rebase

The newer git is pretty clever and the command tips seen in the CLI output is often very useful. I believe it can do a stash and pop automatically for you. I also know the 'git svn fetch' automatically does a rebase of your local commits not yet in SubVersion.

This is, if I want to update, and just be left with any merge conflicts in by local changes.

And that is why I trained them from the start to develop in local feature branches, and never directly in 'master' or 'develop' (any tracking branches). Follow that and you will never get a conflict on a 'git pull' again. In fact you don't need 'git pull' then, only 'git fetch' will suffice. Then when you have the time, you can review the latest changes from upstream (origin) and merge those into your local feature branch - when it suits you.

Regards,
Graeme

As I said they *can* be a huge advantage.

> "svn up" is roughly equal to: stash, fetch and rebase (pull?), stash pop. A simple git alias can do that for you all in one command. ;-)

And in a GUI? The only GUI on windows that was to my taste, is Tortoise.

But if there is another GUI, that can do that?
On win, ideally with explorer integration and not custom drawn (its on windows, its hould look (aprox) like a win app)

True it is not the fault of GIT, if there is on frontend that suits me.... But it does not help

And while all this has many advantage, it is not the point. Yes you can avoid (or defer) the merge conflicts. Which is again a good feature. Unless of course you are not interested in deferring them.

Hello Martin,

Martin Frb wrote

> > A simple git alias can do that for you all in one command. ;-) And in a GUI? The only GUI on windows that was to my taste, is Tortoise.

And exactly why I don't bother with 3rd party GUI frontends. They *all* lack git features.

I found SmartGit (Java based but uses SWT toolkit so looks native everywhere) tolerable for basic commits and reviewing the commit log. But as soon as you get to things like cherry-picking, rebase, rebase --onto, commit only specific changed lines of code from a file, SVN repo integration etc... Then those GUI's just stumble or are more complex and confusing than the command line. [my personal opinion obviously]

Regards,
Graeme

Well and there we are: For people who want/need/prioritize a GUI, GIT is (for no fault of its own) not always the best choice.

For me
1) it is usability, mainly the gui, well, and other stuff like the un-memorizable hashes.
2) too much freedom :) svn forces me basically to finish patches: if I started to modify something, it is the easiest to finish it than to store it somehow away. git doesn't, just commit when being disturbed, add an unfinished in front of the commit message and I can/will continue with something else when I come back. For an "idle" time project like FPC this is really a problem for me: my git-svn copy contains currently around 60 unfinsished branches :(

And of course in case of FPC the huge effort to switch the whole infrastructure.

That scares people. That is why I introduced the developers, at my previous employment, to git by simplifying things. I let them use a client/server workflow model. That seem to have helped them a lot, and get over that fear they had.

But why do you use Pascal then? All these projects use C/C++, probably also for a good reason.

Hello Florian,

Florian Klämpfl wrote

But why do you use Pascal then?

Sadly, I'm slowly moving to Java. Go where the work is.

Regards,
Graeme

Apologies for resurrecting a fairly old thread, but I've been doing a bit of digging for my own interest and want to challenge Graham on one or two points.

Before anything else, I think it's reasonable to assume that Git is here to stay, in the same way that CVS was here to stay: there might be something better in the future, but for now it's something that a developer has to know about.

As I understand it, Git is not only distributed but decentralised. That is, the cooperating developers maintain an undirected graph of Git instances, there is no single master repository: if the project owner's servers go down it is not possible to guarantee that the project can be reconstructed to an extent that would satisfy e.g. a court investigating intellectual property ownership, and that is going to spook corporates and their lawyers and should be a concern to free software advocates who might need to establish precedence and "prior art".

Now I am sure that Git advocates will point out some bolt-on accessory that turns Git into a tree. But when the Git designer (who, I grant, is not the current maintainer) is happy to say "You are stupid" to anybody who doesn't see things his way, or "You should be in some mental institution" to people who find that CVS fits their way of working, one has to wonder whether the Git community really would commit themselves to that sort of hybrid.

By way of comparison, Subversion has a single, master repository generally maintained by the project owner or his agent. If the machine crashes he should be able to restore from backups (tape, cloud or whatever) and forensic inspection of the failed disc would probably be able to confirm that the restored repository was a fair copy of the lost one.

The problem with Subversion is that it's entirely centralised. Leaving aside Torvalds's arguments about the performance implications ("Merging in subversion is a complete disaster [...] and their plan sucks too."), I don't think there's an officially-sanctioned way of building a tree (or even a star) of caching servers. There used to be something called SVK, but even that would only allow a single layer of local caches: there was no provision for a group of programmers to have networked connection to a departmental server which was a reliable copy of the project owner's system.

So it seems to me that one has to concede that Git and Subversion between them have pretty much swept everything else off the board, at least from the point of view of unpaid developers and free (money and beer) projects. Which is unfortunate, since for all its bluster about cryptographic consistency checks Git is deficient when it comes to guaranteeing that there is a single master copy of a project, and for all its accumulated good reputation Subversion is deficient when it comes to extending the network architecture and enforcing fine-grained security.