Well, if run from cmd then yes, as far as I tested.
If run from a unix like sh/bash/... then no.
Well that is something.
First of all, git expects to be run inside the repro dir (can be in a subdir, but not outside). At least afaik.
So most of the time you switch into that dir first.
When I wrote it, I was mainly thinking about export, but also to reduce commands to single lines again, since git seems to often need multiple commands with options for simple operations.
Helper apps to embed the checkout hash into apps also matter.
Though maybe tortoise git will eliminate them. And maybe I should lighten up on the scripting front since I won't have to recreate the heaviest ones.
True. The example was bad. It was just a remark about not wanting to invest heavily again, since this might also be temporary again. For windows users doubly so, since the degree to which git+associated tools are ported to Windows might vary over time.
s/git/svn/ => and the statement is either as likely as, or even more worrying.
No. SVN was well integrated into Windows from the start. It didn't come with bash, and all needed basic commands were single issue without the need for scripting. It also needed minimal configuration. (though still more than CVS, but that was because CVS had awkwardly weak authentication/encryption)
This is why
I think the fact that any software might cease to exist (entirely or partly) is not an argument (unless there are actual signs that it is about to happen.)
We'll see. I just got horrible vibes from everything GIT. The constant pushing of bash might have been something that triggered me.
Here we could same as good say, Windows users may have a problem, because Windows may cease to exist (it already has a subsystem for linux, it may just drop the system around it, and be linux in itself...)
Nobody knows anything what will happen on the real long term. Usually it is also never so black and white, technologies more often change markets and heavily mutate than outright disappear.
But yeah, the year of Linux on the desktop might finally happen, and Linux might break out of its current server and power user audience. But I won't hold my breath after hearing such things about Linux longer than that I use windows.
The naive user sees the name of the product survive and assumes continuity that is not really there in reality. This is the danger of superficial analogies like the car one that you produced..
That something survives doesn't mean users on all paths are safe. Zeppelins still exist, but aren't as dominant as some people would have hoped. And then I'm not even asking Hindenburg passengers for comments ;-)
All joking aside, just survival of a concept doesn't mean that details investments are safe. To stay in your car analogy, early movers in post combustion car are writing off investments in hybrid vehicles because in many markets all electric is moving much faster than expected.
Yes, that is the nature of change. It usually requires investment. And if it is done correctly, in the end the benefits will be more than the cost.
However, the distribution of benefits and cost is not always fair. Some loose out, some win. The aim is that the amount of winners is massively higher.
If a proper cost/benefit analysis was done in the first place. I'm not convinced this is actually the case.
Compiler devels wanted (easier?) forward and local branches, and the server was up for renewal which was tempting for the people maintaining the infrastructure. And that actually forced the issue, not the GIT "features".
All the rest is piled sentiment on to make it palatable.
...Of course existing scripts (or fpc apps) that call svn, must be changed ...
That is a once off for git.
It was a one of for subversion too at one point :-)
So you agree?
I guess you talk about the CVS to SVN?
Yes. But that was different, because subversion had advantages for all user groups, not just a happy few that heavily use forward branches.
Also CVS development actively point to SVN as a successor, it was leaving a phased out (EOL) product. This is not the case with svn->GIT, and the tools are in many case a regression with git.
So did the change for fpc turn out to be good? Or would it be better, if fpc was still using cvs?
Definitely positive, but it still cost the project over an year, and while a bigger change in feature set, the amount of features used from the VCS was actually less. Little scripting and fixed procedures (e.g. for release and fixes branch maintenance).
So I expect it to be worse in this case, with smaller gains (which are also very unevenly distributed, and for some it might remain a netto minus).
I was initially negative about CVS->SVN too, I considered the change not worth the advantage (which back then for the common user was mostly renaming, though also back then the compiler devels were only interested in branching).
But when the migration got closer and more detailed, I got more positive. Many small things were better. Also the EOL status became more prominent in the period between initial talks about migration and the actual transition. And Peter (and Jonas too iirc) prepared it very well.
Neither of those cases are now the case. The windows tooling is a step back, the commands are more complicated, the preparation less. And most importantly, SVN was not EOL.