Actually, git appears to be a workflow tool; advocates use it for more than source control. Hence the complexity, and hence I have little use for it.

I am not sure what you mean. Git is explicitly a VCS:

"Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency." — https://git-scm.com

It was written to replace BitKeeper because the owner said the Linux team was reverse engineering its proprietary protocol.

Linus Torvalds wrote it, trying to do something different than CVS and Apache Subversion. It's a distributed system, so it is very different from those centralized options.

In any case, it is definitely version control software.

 

So Source Forge has Git as an option but also has other alternatives. Might one of those be easier to use than making the investment in learning Git?

You should learn git, and/or use one of the graphical frontends for it. Git is not that hard. It takes a little work to get used to it, but you only need a subset of commands and it is pervasive.

 

In any case, it is definitely version control software.

Perhaps my distinction is a bit subtle. Traditionally version control systems were pretty simple. We used to call it configuration control: a configuration was essentially a project or library, and it was comprised of source files, each having a history. Versions were recorded and and changes were made with comments entered for each.

Git offers the same functionality with a whole lot of extra features for what I call workflow. This is why they have things like stash, cherry pick, and God knows what else. Most everyone agrees git is ridiculously complicated, no doubt offering workflow features some people consider worth the complexity.

My last client bait and switched us from SVN to git and I had to work with it. In order to get my changes into the repo I had a 13 step procedure written that needed to be followed to achieve my goal. Any variation on that list and I was screwed.

It's classic Linuxism. I think advocates tend to like to show how clever they are by doing things the absolutely most difficult way possible. (Vi anyone??) I have no time for that.

Anyway, I didn't bring up git. I merely suggested that I am considering cloud storage but would insist on storing encrypted files. Don't need people snooping in my stuff.

 

My last client bait and switched us from SVN to git and I had to work with it. In order to get my changes into the repo I had a 13 step procedure written that needed to be followed to achieve my goal. Any variation on that list and I was screwed.

It's classic Linuxism. I think advocates tend to like to show how clever they are by doing things the absolutely most difficult way possible. (Vi anyone??) I have no time for that.

I'm sorry but I have to disagree with you. You had someone using git badly. That's not git's fault. You can use git for version control in the same way you use SVN or CVS, there are even scripts that work git through familiar SVN/CVS commands.

On VI, that's much older than Linux and has a bad reputation because the learning curve is steep, but it is both powerful and actually easy to use by learning a small number of commands. You can learn more, but you don't have to.

Git, like VI (actually, VIM) are literally everywhere. Anyone working with UNIX-like systems and F/OSS does themselves a disservice if they do not learn the basics at least. Every person I have mentored learned both well enough to use them, and found it easy after the initial start.

I think people need to know that things aren't necessarily as you are presenting them. I'll not talk about it further, your opinion is yours to have.

 

Git, like VI (actually, VIM) are literally everywhere.

Exactly. I absolutely loved Vi. In 1986. I lament the lack of innovation. Next let's talk about Agile/scrum. Our industry isn't perfect by any means.

 

GitHub stores your source code and all change history, developers therefore have two physical copies one in GitHub and another locally on their hard drive, so it is backed up in that sense, GitHub have huge infrastructure facilities and is quite resilient and its free too unless doing something out of the ordinary.

Git isn't really complicated but the obsessive use of the command line by many users certainly makes it look complicated, using a GUI tool like SmartGit means you don't need to use the command line ever, every operation can be done with a mouse and the tool's menus and so on.

Years ago I also backed up an entire source folder tree each evening and zipped it, I look back and wonder just how much more productive I'd have been if using Git back then, it would have freed up huge amounts of time.

Getting away from a manual backup and zipping process for code is perhaps the single best decision one could make as a software worker, I cannot overstate that.

I'm very familiar with Git and learned it the hard way, hardly any help, lots of command line fiddling around and so on, this was at at a job I had some years ago where Git was their backbone source control. One day everything just "jelled" and I understood it, it is not complicated at all, but is not taught very well.

 

GitHub stores your source code and all change history, developers therefore have two physical copies one in GitHub and another locally on their hard drive, so it it backed up in that sense, GitHub has huge facilities and is quite resilient and its free too unless doing something out of the ordinary.

Granted but backup is multiple, geographically diverse copies. The original isn't a backup so it's not one of the copies. A repo on GitHub is a great part of a backup strategy, but you don't control it, it there is a non-zero chance it could become inaccessible.

I am not arguing against using a repo as an element, only that it isn't backup by itself, the local copy notwithstanding. I suppose you could use bitbucket as well, but you should have a copy in your direct control.

 

Granted but backup is multiple, geographically diverse copies. The original isn't a backup so it's not one of the copies. A repo on GitHub is a great part of a backup strategy, but you don't control it, it there is a non-zero chance it could become inaccessible.

I am not arguing against using a repo as an element, only that it isn't backup by itself, the local copy notwithstanding. I suppose you could use bitbucket as well, but you should have a copy in your direct control.

The code resides in at least two places - GitHub's system and your local machine, so if your machine dies the code is in GitHub and if GitHub go offline (as they do very occasionally) no problem, you have all the code locally.

One could use BitBucket too, in parallel so long as new locally created commits are pushed to GitHub and BitBucket that would work.

One always has direct control over the repo on their machine, pushing changes to GitHub is - more or less - a backup step in and of itself.

 

The code resides in at least two places - GitHub's system and your local machine, so if your machine dies the code is in GitHub and if GitHub go offline (as they do very occasionally) no problem, you have all the code locally.

One could use BitBucket too, in parallel so long as new locally created commits are pushed to GitHub and BitBucket that would work.

One always has direct control over the repo on their machine, pushing changes to GitHub is - more or less - a backup step in and of itself.

Backup is in the event the local copy becomes unavailable so it can't be counted among the backup copies. You could say the local copy backs up the remote one, but that's not the goal. My rule of thumb for all client systems is three geographically diverse copies. One can be offline instead of online or near line. But when defining backup, local copies don't enter into it.

I had to be sure that data had very little chance of being lost, and creating these strategies was a serious business. In the less formal cases, like this one, the rules still provide good guidance.

 

Ideally what I would like to have is something of limited capacity that I would not have to pay for and that was publicly accessible.

My friends and family solution is also Dropbox. Cross-platform, a reasonable amount of storage for free, and it works pretty easily.

As a webmaster for several sites, I can set up a fairly nice file-sharing service using tools provided by my hosting company, Godaddy. Handy tools for previewing and even editing photo files are available. No space limit. But even those solutions that are free to me have shortcomings - in particular the maximum upload size is capped at 100Mb or something like that. It's usually easier to just use Dropbox.

 

Backup is in the event the local copy becomes unavailable so it can't be counted among the backup copies. You could say the local copy backs up the remote one, but that's not the goal. My rule of thumb for all client systems is three geographically diverse copies. One can be offline instead of online or near line. But when defining backup, local copies don't enter into it.

I had to be sure that data had very little chance of being lost, and creating these strategies was a serious business. In the less formal cases, like this one, the rules still provide good guidance.

For private repos that contain just my stuff, hobby etc GitHub is how I backup my code, I simply push commits at the end of the day and move on.

Nobody sees or needs to see these repos because I'm simply using GitHub as my backup service to all intents and purposes.

There's always a possibility my drive can fail but I don't care at all because the code is safe in GitHub.

The possibility of GitHub losing data is almost zero, read about GitHub Spokes.

 

What happens if you have a fire? To be most effective, backups should be automatic and distributed.

Notice I mentioned a "external" type of drive as my 3rd copy. It can be stored in my workshop, a totally separate building a hundred feet from the house. True, both buildings could burn down by some fluke, but I'll chance it with that remote possibility. An asteroid hit could destroy both locations at the same time, but I think my computer backups will be the least of my worries at that point.

 

Many banks and other large financial institutions have very serious disaster recover plans, they regularly carry out trial exercises too. I knew of one large investment bank in London that had huge trading floors, they also had a complete replica situated in another city, all setup, connected and ready to go.

The plans are very involved, step-by-step instructions and each person who needs to be involved has their own copy of their part of the plan.

These kinds of plans were activated several times, one was in London when the IRA bombed the financial center (I think I still have photographs that I took of that) so think about this next time you do a backup!

 

I initiated CAD drafting on our plant using the 80286 computer w/ the 80287 math coprocessor. Eventually, they added 3 more CAD stations. Backup was on SLOW external tape data cassettes using a Centronics SCSI port. Which were stored in a remote building with the mainframe backups and rotated out so we had a minimum of 2 backups remote and a used tape cassette ready to use. Things have come a long way since then. You really need to put some thought into your backup and restore strategy.

 

My last client bait and switched us from SVN to git and I had to work with it. In order to get my changes into the repo I had a 13 step procedure written that needed to be followed to achieve my goal. Any variation on that list and I was screwed.

It's classic Linuxism. I think advocates tend to like to show how clever they are by doing things the absolutely most difficult way possible. (Vi anyone??) I have no time for that.

Anyway, I didn't bring up git. I merely suggested that I am considering cloud storage but would insist on storing encrypted files. Don't need people snooping in my stuff.

I understand and partly agree with the characterization "Linuxism" there can be a degree of elitism sometimes with the whole Linux world, stems from a similar thing I saw with Unix and AIX and stuff back in the 80s and 90s.

I am not particularly impressed by Unix or its many variants, frankly 1960s ideas being touted as cutting edge innovation.

The command line on these platforms is almost an obscenity, completely non intuitive, overly complex sometimes and far from consistent or uniform across applications.

I've worked professionally on several platforms and specialized for a while on Stratus fault tolerant systems in the 1980s and early 1990s, that system had an OS named, simply "VOS". Turns out that was a rewrite (it seems) of a robust implementation of Multics, the seed that gave rise to the mutant we all know as "Unix", there are few similarities between these.

Multics was well designed, thoughtfully designed by engineers solving real problems and a view to competing in the marketplace.

Many things we take for granted were first implemented within Multics, one example, Multics was the first OS written in a high level language (PL/I), it was likely the first OS too to even use a command line concept and the way Multics handled that was far slicker than Unix ever did.

Anyway, I digress.

Back to GIT, I struggled with Git for some months about 6 years ago when I started a job that used it heavily, the technical teams there were very very good, many ex-Microsoft people, very competent software developers, but I struggled with Git because I could never get simple answers to simple questions, everything was "command line" and the cryptic nature of that was unfathomable.

What didn't help is the way Git uses established source control terms in new ways, for example "checkout" does something quite different to what it usually does in other VC systems and that makes it harder to learn because we each carry a preconceived notion of these terms and when we see them and use them its very difficult to dissociate them.

Nevertheless I did persist in learning what was going on (I had to, it was my job and I was expected to master stuff like that) and eventually within the course of a week or so, after like four months on the job it just crystalized, became crystal clear, an epiphany.

Now many years later I can speak confidently about the system, I've been through my struggles and scrutinized the system in minute detail and understand it pretty well. I introduced GitHub to the company I now work at and it has become entrenched, an established part of the company's IT strategy (we were using TFS).

So having said all that, I also say GIT is very very well designed, what it does and what it can do is extremely well thought out, the problem is that the emphasis on command line usage and the reuse of older, established industry terms (checkout etc) can completely mask this and easily create a negative first impression as it did with me initially.

BY avoiding the command line altogether, you will find learning Git much more rewarding and will learn it faster too, I've used probably every Git GUI there is and without doubt SmartGit wins hands down.

SmartGit is written in Java and so runs on Windows, Mac, Linux no problem. SmartGit is also well written, it has never misbehaved, crashed or caused me problems, it is also feature rich and can do stuff with a few mouse clicks that would otherwise take a bunch of cryptic commands to accomplish.

The history is displayed graphically too, in that history I can click on any commit in the past and see what files contain what changes, I can even right-click a file and choose to save it as it looked before the change or as it looked after the change, this is great when we decide that we simply want to get some particular file back to the way it looked months ago.

If you write software anything other than the most minor dabbling, then using Git will greatly accelerate the ease and speed at which you work.

 

I've a theory as to why Linux is inherently and forever archaic. Much of computing innovation, particularly performance is driven by: Gamers! Obviously that includes the game software. And I've seen that Linux advocates pretty much refuse to pay for software, only kicking and screaming if forced to do so. Therefore, high performance hardware has little vectoring into the Linux world, or at least lags other platforms significantly. This explains the command line adherence as graphics adapters were key to developing GUIs and window managers.

then using Git will greatly accelerate the ease and speed at which you work

See, as I said, git is a workflow tool!

 

The command line is decidedly not an archaic holdover for elitists. GUIs have their place, but the command line is all about facilitating automation and configurablility. When it comes to productivity, there's simply no comparison between command line and graphical interfaces.

 

The command line is decidedly not an archaic holdover for elitists. GUIs have their place, but the command line is all about facilitating automation and configurablility. When it comes to productivity, there's simply no comparison between command line and graphical interfaces.

The command line concept is good if done well, the problem I have is that Unix and then other systems did this poorly.

The way each command or app uses command args often varies wildly, the idiosyncratic naming and other things often end up presenting a hugely disorganized and confusing experience for people.

 

The command line concept is good if done well, the problem I have is that Unix and then other systems did this poorly.

The way each command or app uses command args often varies wildly, the idiosyncratic naming and other things often end up presenting a hugely disorganized and confusing experience for people.

The defacto standards for Linux/UNIX CLI programs is pretty consistent at this point, the man page facility and --help make working out the differences relatively easy. Pipelining—the original innovation of UNIX—is alive and well. It works pretty brilliantly. As a sysadmin, the shell is a prodigiously productive place for me. I use bash scripting with pipes, and sometimes perl to get a lot done in a very compact space.

Is there room for improvement? Of course. But the evolutionary growth of the Linux command line has given us a really great environment which, in my opinion, has far more pluses than minuses for this who practically use it.

 

The command line concept is good if done well, the problem I have is that Unix and then other systems did this poorly.

The Unix-style command line is brilliant! The Unix philosophy is "each command does only one thing, and does it well". Using a shell, these single-use commands are piped together to solve complex problems, and since the shell is scriptable, everything can be automated.

The way each command or app uses command args often varies wildly, the idiosyncratic naming and other things often end up presenting a hugely disorganized and confusing experience for people.

Almost every command knows what '-h' and '--help' mean, and that's enough for most simple commands. More complex apps have a learning curve, but like anything else the more you use it the more it becomes muscle memory. And some stuff you just need to learn (or copy/paste) once, and then forget it. I can never remember awk's syntax, but that hasn't stopped me from successfully using it in various scripts. Automation is the key. I script anything that I do repetitively, and things that I do only occasionally but is painful to do.