Git Developers Want Your Feedback (2016 Git Survey)

[timofonic]

It'snot the lack of obscure ssh clients so much as Windows not having an inbuilt sshd. That is painful.

I miss more a standarized way of having the features of following software: Mosh Screen/Tmux/Tmate, Wemux, notty....

And of course, implemented in PuTTY and supported by BSDs & Windows too. Isn't Windows 10 becoming more Linux-friendly and able to run Ubuntu userland? :P

[curaga]

Been using git for something close to a decade, and today I learn it can do --color-words. Since 2009. Happy as a puppy, but git really has some of the most well-kept secrets in every subtool.

[SystemCrasher]

It's still puzzling me: svn doesn't even know what a branch is and cvs is worse. And yet, I still have to argue in favour of git...

Actually, CVS and SVN aren't even version control systems, they're rather "downloaders" who do some very basic management of file versions. If one attempts to actually move between versions (that's what VCS for?!) they'll soon learn SVN and somesuch are damn slow at that and redownload half of project each and every time you actually want different version. And can't do anything meaningful without connection to server. So when it comes to fiddling with versions, SVN is utter crap and just happens to be older generation of technology from ages most humans had no good ideas it could be done better than that. Good luck to do e.g. something equivalent to "git bisect" (and have fun redownloading whole thing multiple times).

Whatever, git does what DVCS is supposed to do. Those who got stuck to older tools are basically punish themselves by using awkward inefficient tools.

[bug77]

SystemCrasher Yet svn is way, way easier to pick up then git. That's why people go svn first and then they find it difficult to move on. I don't think git would be perceived to be as hard to pick up is svn (and p4, clarify, whatever) wasn't so simple.

[unixfan2001]

SystemCrasher Yet svn is way, way easier to pick up then git. That's why people go svn first and then they find it difficult to move on. I don't think git would be perceived to be as hard to pick up is svn (and p4, clarify, whatever) wasn't so simple.

I used to think the same, back when I was working for a small OSS shop. Then (long after I had left that company and signed up with one using svn) I actually gave git a try on my own, in the privacy of my home.

Today I can't even remember the reason I thought git was more complicated. Nor can I remember any svn commands...

[unixfan2001]

Oh yea. I'm on the last stretch of transitioning a company of 6,000 from svn to git.
Been quite the ride but most of my co-workers find git somewhat exciting. Already saved our butts once.

[GreatEmerald]

SystemCrasher Yet svn is way, way easier to pick up then git. That's why people go svn first and then they find it difficult to move on. I don't think git would be perceived to be as hard to pick up is svn (and p4, clarify, whatever) wasn't so simple.

I haven't seen anyone bothering to explain SVN nowadays. Why bother, when in reality you're going to use git anyway? Plus there's things like GitHub that don't require in-depth explanations either.

[bug77]

Today I can't even remember the reason I thought git was more complicated. Nor can I remember any svn commands...

But that's like saying the solution to a math problem is easy, after you know the solution.
The problem I had (and I suspect other as well) is that in centralized VCS, there is only one actual repository. In git there are many and (the not-so-intuitive part), they're not bitwise copies of each other.
You can be proficient with svn et al in a day (hours, actually).

[SystemCrasher]

SystemCrasher Yet svn is way, way easier to pick up then git.

Git got far more features. So advanced things could take some efforts to learn, sure. However, basic things are IMHO fairly simple and when I need git to do smth, most of time it does exactly that, the way I suppose it should work. It does not takes a lot of commands to get started. So I can't say I've spent considerable efforts learning git. I just type what I think is going to work, if I'm really unsure, I read man or google it. These days bash also got fairly decent autocompletion so bash would readily give useful hints once I hit "tab". Therefore I'm unable to agree with your statement.

OTOH SVN...
- Branches... erm, well, svn is fucking file downloader. Its notion of branches is fake, it does not works the ways it meant to be. Scrap that.

- Linear timeline instead of parallel/semi-independent development? Retarded bullshit. It screws development up a lot. Especially in larger projects which could be split to several semi-independent subfeatures. SVN learns ppl to do it fundamentally wrong. Just don't do that. If you did, scrap that. Its defective by design.

- If I want to take a look how certain project performs... "git log" gives me idea what's going on. Git log -p allows me to grind into details. How I'm supposed to track project progress with svn? It just does not works. So svn is of little help to tune-in and remain in-sync. So one gets plenty landmines on the way. Just becuse their version control tool suxx. Really poor excuse, eh?

- Git bisect kicks the ass. Like half of weird bugs could be squashed that way, esp. regressions. Other ways to track them could be painful and slow. It could save a day when you need plenty of new features, minus one pesky regression/newly introduced bug. While it is theoretically possible to do something like git bisect with svn, in practice it probably not going to be feasible for performance and convenience reasons.

- To get SVN work, one actually needs SVN server. Setting up SVN server is hardly easier than setting up local git repo for one dev, and way too restrictive for team development on workflows.

That's why people go svn first and then they find it difficult to move on.

I've used svn just one reason: git was not there when I've started using svn. There're no good reasons to use svn when there is git :P.

I don't think git would be perceived to be as hard to pick up is svn (and p4, clarify, whatever) wasn't so simple.

Git just does things right. It does not interferes even if it going to be single developer on local machine. In fact one could save considerable efforts on e.g. svn server setup in this scenario. OTOH git is flexible in way ppl would exchange their data and brings power of independent/parallel development, which scales really well. And I'm sorry but I consider linear development model to be outdated and inefficient.

[bug77]

SystemCrasher I'm not disputing any of your claims. But learning svn is like learning Basic. A simple language that you pick up easily and lets you do stuff. And then someone comes and tell you about C. We all know you can do real work in C, but since you don't know the rewards that await you, you might just conclude that C is an unnecessarily complex language and Basic is more user friendly. And you wouldn't be 100% wrong either.

As for reasons to use svn, what about "the team already has a svn server in place and they don't know git"? I use git-svn when this happens, but I had the nasty surprise of a svn repository being somehow misconfigured, making it impossible to clone with git

And about branches, at least svn is honest about it and it doesn't even have a "branch" command (or "tag" fwiw). It only has "copy". Once you get branches and tags out of your way, things become a lot simpler