US Hawks Hang Gliding Association

Git is a version control system created by Linus Torvalds.

From Wikipedia:

Wikipedia wrote:Git is a distributed version-control system for tracking changes in source code during software development. It is designed for coordinating work among programmers, but it can be used to track changes in any set of files. Its goals include speed, data integrity, and support for distributed, non-linear workflows.
    :
Git was created by Linus Torvalds in 2005 for development of the Linux kernel, with other kernel developers contributing to its initial development. Its current maintainer since 2005 is Junio Hamano. As with most other distributed version-control systems, and unlike most client–server systems, every Git directory on every computer is a full-fledged repository with complete history and full version-tracking abilities, independent of network access or a central server. Git is free and open-source software distributed under the terms of the GNU General Public License version 2.

This topic is dedicated to helping people understand how to use Git in general and how we might use it for various U.S. Hawks projects.

There are a number of very good Git resources on the web. Some of the most authoritative are:

      https://git-scm.com/
      https://git-scm.com/book/en/v2

Other good resources include:

      https://guides.github.com/introduction/git-handbook/
      https://thenewstack.io/tutorial-git-for-absolutely-everyone/
      https://towardsdatascience.com/getting-started-with-git-and-github-6fcd0f2d4ac6

While those are all useful (and I'll update the list as I find more), they are still fairly technical for our use. So I'll try to give a simpler view here.

In its simplest form, Git is really a database that keeps a copy of some of your files and a history of their changes. The database can be on your local computer (usually hidden in a subdirectory named ".git"), or the database can be stored on a remote server like GitHub.com or GitLab.com or any combination of those options. It's the same database in all cases, and that's one of the true beauties of Git. There really is no central server. Everyone's copy of the database is as functional as everyone else's. And the best part is that Git has mechanisms to support merging these databases so people can more easily share their work. Web sites like GitHub and GitLab are really just convenient places for people to exchange their Git databases with each other.

O.K., so Git is a database. What does that really mean? How about a practical example?

Good questions. Let's get started ...

Suppose you've got some files (computer files of course) that you've been working on. They could be several files. They could be just one file. They could be a hundred and eighty seven files spread over 39 directories. They could be anything - computer programs, letters to your Mom, a training manual, or a web site full of hang glider pilot ratings. Regardless of what they represent to you, Git will see them as a collection of files to store in the database.

So you start out by telling Git to keep track of those files:



Well, you don't do it exactly like that, but that's the general idea.

So you go on and make some more changes and add some more files. Every once in a while you stop and tell Git:



And Git will do just that. It will keep adding changes to the database and give each new change a unique ID so you can get back to it later. You can add new files and folders. You can delete and rename things, and Git will keep track of it all. You can tell Git to "rewind the clock" to any point in time and Git will give you a copy of your files as they were when you saved them. It keeps all of that history in its database.

Now that's pretty cool so far, but the best part is yet to come. Not only can Git keep a database of your own changes, but Git can merge your changes with changes that other people make to their own databases. You just merge your databases together from time to time to keep in sync with what everyone else is contributing to your project.

The merging can be done "the old fashioned" way with a floppy disk (yes, my age is showing), or you can share databases over the interwebs. That's where sites like GitHub and GitLab come in. They are really just convenient places to share Git databases. You can share databases publicly with everyone in the world or just privately with a small group of people. You can even keep databases private for yourself. You can set up the databases so that some folks can see them but can't change them. You can give change permission to whoever you want so they can merge their changes into the shared version. You can even make separate "branches" for various versions, degrees of completion, and stages of approval.

As mentioned in the previous post, there are a number of web sites that are set up to support sharing of Git databases. Two of the best known are GitHub and GitLab. They both allow free accounts and free databases. Of the two, GitLab is considerably smaller, and I think that causes them to offer better terms. So while they are both similar, I prefer GitLab, and that's the site I'll be experimenting with most in this topic.

To get us started, I set up a Git repository (fancy name for a database) on GitLab. Since several of our members have had a keen interest in preserving hang gliding history, I set it up to be a history web site:

      HistoryOfHangGliding.gitlab.io

Here's what it looks like at this time:


Now this is NOT intended to be the gold standard for hang gliding history. There are many better sites already out there (see HGHistory, U.S.Hawks History Forum, EnergyKiteSystems, USHGA.aero). But it IS intended to show one avenue for people to collaborate on a shared project using existing tools ... and for free.

So with that thought in mind, if you'd like to learn how to use GitLab on a fun hang gliding project, please chime in here and we can get started.

By the way, I chose the topic of hang gliding history for this GitLab project because EVERYONE has some parts of the history puzzle that they can share. It might be monumental history like being at the first Otto Meet, or it might be tiny personal history like the first time you ever saw a hang glider in flight. They are both unique experiences that we can all share and enjoy.

USHGRS.org is offered to all interested to be morphed to a collaborative git repository. May every hang glider pilot in the US keep her or his ratings as HG pilot forever. And further, all detail of hang gliding history noted in any of my sites may be merged into pilot files of such repository; any participant in growing the repository may merge matter into pilot pages or the like; all such without permission further from me. May enthusiastic repository builders help make a gem for all.

JoeF wrote:USHGRS.org is offered to all interested to be morphed to a collaborative git repository. May every hang glider pilot in the US keep her or his ratings as HG pilot forever. And further, all detail of hang gliding history noted in any of my sites may be merged into pilot files of such repository; any participant in growing the repository may merge matter into pilot pages or the like; all such without permission further from me. May enthusiastic repository builders help make a gem for all.

Joe, my Friend,

You have been carrying the ball on your own all this time. Using tools like GitLab will give you a team to help you.

But you should retain the primary leadership role at USHGRS. Maybe you'll lead as the quarterback or maybe as the head coach. But you should be at the helm one way or another.

It just dawned on me (as I was writing this) that USHGA would have been a better organization over these past 40 years if you had stayed at the helm there. Please stay at the helm of USHGRS. Your friends will step up with collaborative tools and with hands to do the work. But we cannot easily replace the steady vision and wisdom that you bring to the effort. Please stay with us.

Big Thanks to Craig for 2 things:

      1. Volunteering to help work out the kinks in our GitLab projects.

      2. Finding a gaping hole in my instructions (see below).

I've been using GitLab in my work for years now. It's great. But I forgot that there are two ways to sign up for free. They have the regular Free Registration process, but they also have a Free 30 Day Trial. I am not sure about the difference, and I don't know what happens at the end of the 30 days.

But I recommend that people start with the regular Free Registration shown circled in the upper right here:



Maybe the 30 day trial will fall back to the normal free registration after the 30 days. I don't know if that's true or not. But if it is, please post to let everyone know how it works. And if anyone wants to spend a little for the paid subscription, that's good as well. It's up to you.

Thanks Craig for finding that potential pitfall. That's why it's good to have lots of people trying it out.