Welcome. We are going to wait a few minutes before we get started. But just hang tight. I'm going to give it until 1202. And then I'll get us going. To have a deadline. The session I was in this morning for ESA. The folks coming into the session. Typically had to go through about three different sort of stages to get into the zoom meeting. So. It was, it was. There's an emerging norm to wait about five minutes. For everyone to navigate their way in. That makes sense. Hi, Chris. See Chris Scott. Awesome. Okay. I am going to get started. Welcome to the New Mexico smart grid center, GitHub training webinar. I am Brittany Van Dwarf, the communication and outreach specialist. I am a program for New Mexico. It's a nationwide program funded by the national science foundation. I will be your host today. Along with my co-pilot Isis or not our website and minister. Who will be managing slides, feeling questions and working behind the scenes to make it all close smoothly. A few housekeeping things before we begin. I want to let you know that you have questions at any point. Isis will interrupt John or Carl and read them aloud. So. John or Carl can answer. I also wanted to let you know about the fantastic lineup that we've put together for spring 2021. Go ahead. Isis in advance. The next webinar will be on March 24th, where we will hear from a New Mexico, New New Mexico smart grid center faculty member, Claus Danielson, who will be giving a talk entitled exploiting symmetry in large scale optimization and control. Next is April 28th by another New New Mexico smart grid faculty member, Hamid Nadimi. And his talk will be control and interoperability challenges in new energy and E mobility systems. And finally, on May 26th, we will have an Opal RT for beginners webinar led by New Mexico smart grid center graduate student, Rusty Nail, who works with Olga Lavrova at NMSU. So keep your eye out for our monthly newsletter where you can find more information and registration details. Okay. Now that we are through all the housekeeping stuff. I wanted to take a moment to welcome our presenters today. It's Carl Benedict and Jonathan Wheeler. And without further ado, they're going to share their knowledge about GitHub training and take us away. So I'm going to turn it over to you too. Thank you so much for being here. The floor is yours. Great. Thank you. And I just want to take a second while I'm sharing my screen to thank you, Brittany and thank you, Isis and everyone at Epscore for coordinating these workshops and these webinars. It's a great opportunity to work together and to explore some concepts that can really be used to improve and facilitate workflows and collaboration with greater efficiency than we may be used to in some of our existing use cases and some of our existing workflows. And so I'll give you a little bit of background about myself. My name is John Wheeler and I'm the data curation librarian at the University of New Mexico libraries in the College of University Libraries and Learning Sciences. I've been here since 2012 working in the library's research data services unit with Carl, who's presenting with me today. And we both started teaching these kinds of technical skill concept workshops in 2017 through a ongoing Coffee and Code workshop series, and I'll share a little more information about that in a minute. And back in 2019, we both became certified software and data carpentry instructors. And so we've been doing this for a while in terms of presenting issues about version control, things like using command line interpreters to a broad range of users in a lot of different contexts. And so one of the things I want to share is the information that we'll be giving today. There's a couple of tutorials online that we can make available and have made available. And I'll put this into the chat. And the first is the Coffee and Code workshop materials. This is all made publicly available and open access in GitHub. And a lot of what we'll be doing today will be taken straight from the tutorials and the IPython notebooks that are included at that link. And we also, as I mentioned, we're software carpentry instructors. When we teach software carpentry workshops, we use the software carpentry version control with Git lesson. So I put that into... Oh, I'm sending this to all panelists. Sorry about that. Oh, someone else can... We'll follow up on that. Okay, thank you. And so a lot of what we'll be doing today is sort of a combination of these two resources that we refer to and encourage people to look at and refer to because really when we start talking about Git and version control, we have 90 minutes together this morning and we'll talk about what we're going to cover in that time. But there's really a lot to learn. And there's a lot more to explore in terms of version control and Git and how powerful it can be for facilitating your workflows. So we want to refer you to those things. And finally, when we do these workshops, we found it's very handy to have a collaborative document that people can pose questions and comments to. We can make it available after the workshop for people to refer back to. And so I'm going to share a link to this document that I'm looking at right now. And so please feel free to, once you get that link to our Google document that's on the screen right now, if you would like to jump into there and pose questions or if you're aware of a resource or a particular troubleshooting code or command that's useful for people to know, please be sure just to drop it right on into that document. So how did you want to introduce yourself? Sure. Yeah, I'm Carl Benedict and I direct our research data services and IT programs in the College of University Libraries and Learning Sciences. And my academic background is actually in archeology as I came to UNM now 28 years ago for the graduate program in anthropology and have spent even longer than that focusing on various aspects of data management analysis and visualization initially starting with archeological data, but over the last 20 years or so focusing on a much broader range of data, including a large focus on geospatial data and earth science observations. And for the last six years in the library as John was mentioning in our RDS, our research data services program, it's been a great way to actually interact with researchers across pretty much all the disciplines on especially on the central campus but even in the Health Sciences Center in trying to support a wide variety of data management questions, challenges, planning activities, preservation needs and our version control activities have definitely played a significant role in that as that's one critical tool in the toolbox for efficient data management and collaboration. And with that I'll hand it back to John. Great. Thanks. And so one of the first things we like to talk about when we're introducing Git and version control in general and the concepts that are involved, we like to talk about the use cases, right? Because especially in terms of version control, we're used to thinking of it as more or less for software development and software code and just maintaining the pipeline and tracking changes around that. But we try to present it from the standpoint that there are many other use cases and many other workflows that can really be aligned with a really productive version control workflow. And so one of those being document production. And so we like to start with, and this is attributed to the software carpentry version control workshop lesson, where take a second to look through this. It's a situation where we've all been in and we're all familiar with. You're the young student. You've got that final document and it's ready to go and you're excited. You take it in, you get some feedback on it and now suddenly it's no longer final, it's final version two. And we have this habit of proliferating copies of things. So maybe we don't want to make sure that we don't lose changes that we made to a document. So instead of having overriding an existing copy of something, when we get more comments on it, it becomes final revision six with comments. And so you can see sort of in the humor of this comic here, it's a situation that's probably familiar to a lot of us where we end up with multiple copies of a so-called final draft. And it becomes confusing to tell, well, which one was official? Which one was canonical? Are there parts of different copies that actually have sections that I still want to use to combine into a master document? And so even though a lot of us move beyond this sort of workflow, even with working with binary formats like Word and Excel, a lot of the reason we move on and develop better practices around using these kind of document structures and file naming is because we learn it the hard way, right? And so if you think about things that have come along in the past few years, and this is the notebook that we're referring to for this introduction to the lesson, if you think about something like word processing software and the features that have come along and word processing applications for document production for managing changes and versions, it's an improvement over what we used to have, but you can still run into problems, right? So if you think about with track changes in a Microsoft document, once you accept those changes, it can be very hard to go back and actually see what those changes were or to have any idea of why you made them if you also have removed any relevant comments, right? If you think about the undo feature in something like Microsoft Word, a lot of times you can only undo up to the start of your most recent session when you last opened that file. And so if, for example, you accepted a change that you were tracking and you saved your work, you closed the file, you come back to that file, you may not have a way to recover that change later if you decide, well, what exactly was that about? Should I have taken a second look at that, right? In other cases, such as in Google Docs or in Box, if you're familiar with using Box, the storage service, there's version history, right? And that gives us the ability, unlike with track changes before, where I was saying you may not be able to go back to a complete earlier version of a file through track changes. With version history and these online services, you can actually go back to a specific version of a document, but the difference from one version to another can include many, many changes, right? And what if there's one particular change or edit that you made that you're wanting to undo or to look at? How many different versions of that file are you going to have to load in order to compare one copy or one version to another, right? Another thing we run into with a lot of those, whether it's track changes or using version history in Google Docs or Box or Microsoft Word Online, you run into conflicts when two or more people are working on the same document at the same time, right? I've had it happen. I'm sure a lot of us have had it happen where we had a document in the cloud. I was editing it. Someone else in another institution who was working on the document with me was also editing it at the same time. And one of us got locked out of actually uploading our changes to the online version, which then takes a lot of manual cleaning and a lot of manual reconciliation to correct that, right? To prevent against that, it's possible for somebody who's editing a file to lock it. But that actually then prevents anyone else from working on it, right? And so it does prevent conflicts, but it limits your productivity, right? So the features that have come along for these applications and document authoring software, they're useful, but they don't always scale well, right? And I'm talking about like Word type documents or Word processing applications in this context, but it can expand to things like using spreadsheet applications, Excel, right, and other files. And so to think about how can we address these types of problems with version control, today we're going to specifically be talking about distributed version control. And so Git is an example of that, right? And to just give a very high-level overview of some of the advantages that go along with that, when we talk about distributed in the case of Git, what this means is that every clone of a repository contains the entire history of committed changes that were made to the files in that repository. So whether that is a text document, let's say it's a draft of an article that you're writing, it's your dissertation in LaTeX format. Let's say it's a relatively small data file that has been updated or changed. Or if you are working on code for an analytic pipeline, or maybe you are actually developing a piece of software, in distributed version control and in Git in particular, all of the changes that you've tracked are recorded and made available in each clone, or in this case, each copy of a repository, right? So if you think about if anyone was ever familiar with subversion, where when you were using subversion to do version control, you wouldn't really check out the entire history of a repository and have it with you on your local machine to work with, you would just have sort of the latest snapshot, right? The most current state of the code, right? And this is something I would come back to in a minute, but in Git, and when you're using Git, every clone of a repository is a complete copy of that repository. So where this comes in handy in, again, coming back to use cases that are not necessarily software development, but things like authoring documents, developing spreadsheets, every clone of a Git repository is a backup. So whether you're working with a copy, you have a clone of the repository at your desk at work, and you have a clone or a copy of the repository on your laptop, those actually provide some security against corruption and damage or loss of the so-called master repository that's probably living in GitHub or online somewhere. And so that's a tremendous advantage, and I can tell you that I myself have actually restored lost work and corrupted repositories by just referring to another clone, right? Another advantage of distributed version control and the sort of systems that we're looking at today is this idea of granular change tracking, right? And so there are some caveats here that I'll talk about in a minute, but any change that you make to a file that is being tracked by Git, it's added to a snapshot of the repository's history, and within Git, it's possible to compare any two snapshots to each other, regardless of how long ago those snapshots were taken or how recently. And so we can give an example of this if I come to this actual repository that I'm looking at. And so we see here this idea that this is the workshop that Carl and I are presenting. This is our coffee and code version control, and we have made 36 commits to this. That means that ever since we started working on this in December 2017, we've made and recorded 35 different snapshots of what we were doing to the repository at that time. And if you think about what I said a minute ago where it's very hard looking at track changes if you already accepted a change to go back and find out what that change was later, right? It's very hard if you're looking at the multiple versions of a file that are available in Box or Google Docs. It's very difficult to know exactly what's different between one version and another. And we're looking at the GitHub interface right here.  So, for example, at this point, Carl let us know that he had updated an overview for Advanced Git Workshop with graphics. And more than just knowing who made that change and what the overall annotation or description of that change was, we can actually go in and look at the specific file that was changed for that snapshot, right? And so in this case, we see that green lines were added and red lines were deleted, right? And it gives us the opportunity to go back and say, well, I didn't mean to do that. And there are ways to say I want to undo that particular change. I want to go back to a particular copy of a particular file within my repository. We also have the ability to look at not just a particular file, but we can look at the entire repository at that time, right? So if, for example, and I've done this where I accidentally deleted a file from a project and I committed that deletion to Git and I uploaded it or I committed it and pushed it to the main repository, the master repository, when I realized later I should have kept that file, I can go back to the history of the repository and I can access that file through an earlier version. And it's possible in the Git command line interface that we'll be demonstrating today. I haven't figured out how to do it in the GitHub interface, but it's possible to directly compare, for example, the state of the repository at this commit on April 16th and without necessarily opening up all the commits in between, you can compare that April 16th, 2019 difference with what it was like on August 10th, 2018. You can directly compare these two commits. And this is a concept that Karl and I are going to be talking about in more detail later is what actually is a commit. Another feature of version control is this idea of attribution and accountability, right? So one of the first things that we're going to do when we configure Git later today is we're going to add a global username and an email address, right? And as we've seen, this information gets attached to the commits and to the snapshots that we put into the repository to provide some accountability, right? And some way to follow up and audit what was done and who did it. And so, for example, if we come to this tutorial that we're sort of walking through right now, there's a history feature. And a minute ago, I showed you all of the commits to this entire repository, which includes six or seven files. When we look at the history of a particular file in Git, we can see just the commits that had anything to do with that particular file, right? And we've already looked at what those are, and you can see again that this data rescue Albuquerque user is me. This is a name that I was using at the time in Git for a project that I was involved with. So I did this, my email is attached to this, and I give a description of what I did. We also, if you look at the file here, there's a button that says Blame, right? And this gives us a chance to go, again, in a much more granular fashion than we can do through version management services like tracking changes or version histories in things like Google Docs. This gives us a chance to see exactly what was included in a file at the time of a specific commit, this one being that I changed to use cases to bullet points. And if we want to look at the actual text of the file, how we saw before, the notation of what was deleted and what was added in this case, we can click here and we can really dig into the history of the repository and the history of specific files and versions of those files in a way that gives us so much more flexibility in terms of managing what counts as the most current, the most accurate, or what I like to call the canonical content, right? And I might add here, sort of going back to that PhD comic that John started with, when you're working on a large long-term writing exercise in which you're getting periodic feedback from others, if the process goes on long enough, it's not unusual for the opinions of those other reviewers to change and sometimes reverse. And having a way to be able to bring back deep history of your previous work on those written materials can be incredibly helpful when those folks who are making suggestions that you really need to follow, it can save you a lot of pain and trouble if you're using some sort of version control system that allows you to maintain and if you need to dig into that history. And so I just want to step back for a second, too, and say that what I was demonstrating in terms of that really super granular level of access to the history of changes in a repository and the ability to look at line by line what was different and who made which changes and how did they justify that. For the sake of expediency and demonstration purposes, I was demonstrating that through the online GitHub interface. But if you come back to what I said a minute ago, where every clone of a repository is a complete copy of the history of the repository. It looks like we lost. Oh, here he is again. Oh, okay. Well, I was talking, so can you all still hear me? We can still hear and see you, but you're screen sharing. There we go. Right. But it does feel like it happened. So to do a little bit of version control here, what was the last thing I said before my screen went out? I'll just assume that I was. Oh, okay. Every clone of every repository dot dot dot. Okay, so every clone of every repository is a complete copy of all of the history of all of the changes that were made to that repository, right? And so within the Google, the Google, I'm sorry, the Git command line client that we're going to demonstrate in a minute, there are features and there are commands for accessing that history and for doing those comparisons from commit to commit and from change to change at both the level of the entire repository and also at the level of specific individual documents and files. So I'm going to pause. The last thing we do is give some caveats about this, but I want to take a pause and see if there's any questions. Okay, well do please feel free to type any comments. Okay. And so the caveats and these are also listed in this, in this tutorial that we're working through. Version control at this level really works best for text files, right? And text file types. And so in terms of data, instead of an Excel spreadsheet, that would be a CSV file, a comma separated value file. Instead of a Microsoft Word document, that would be a text format like .txt plain text. Markdown, which actually this page that we're looking at here on the screen, this is Markdown, which is a formatted text format. LaTeX, if you are in a field that uses LaTeX, is a great format for maintaining version control in an efficient way. And in fact, my dossier is online in LaTeX format, and I use it to work through my promotion and tenure process, right? So that really granular line level, line by line, change tracking and auditability that we've seen, it's really only available for those types of files. It is possible, and I have done it, to track binary file types with version control, so that includes things like PowerPoint, Microsoft Word, any type of file that has to be compiled by an application in order to open it. You can do some amount of version control with that. Things like I added a file, I renamed or moved it, really sort of like, I don't know, if you will, the gross motor skills of this type of thing. It's just without the ability to compare specific line by line changes, right? And also a caveat for working in Git and GitHub in particular is that support for large files is limited. And so with that in mind, what we want to do today, because as I mentioned a little bit ago, Git and version control is a large topic. There's a lot of concepts involved. And what we want to do today is really introduce you to what is sort of the basic conceptual workflow that is kind of foundational and fundamental to working with Git and working with distributed version control. You know, so for example, I use the term snapshot a few times. And so what we're going to do today is we're going to talk about what that means and how do you create a repository and how do you add files for a snapshot, how do you exclude files from a snapshot, and how do you record that snapshot into the history of the repository, right? Which again is that big thing that we can leverage, that history we can leverage for this real improvement in efficiency and collaboration. So other topics beyond that, we won't be able to cover really in detail today but I will say other workshop opportunities will be coming up. Like I said, Carl and I, we both teach and host through EPSCORE software carpentry workshops. So some of those will be coming down the pipeline. And we also have our coffee and code workshops that we can post more information about where we dive into a little more detail in terms of version control. And so with that, what I encourage everyone to do, so we're about to launch into sort of the hands-on phase of the workshop here. And I just want to give folks a second to touch base with any questions. Okay. And I'm going to launch the Git shell from my workstation, which is a Windows workstation. If you've already installed it, it'll be under G for Git. And what we want to use today, although there is a graphical user interface, there's various philosophical but in our cases some practical reasons for using the shell. For example, if you're connecting to the EPSCORE cyber infrastructure, you may be working over a network and communicating with a server where all you have is actually a shell environment or a command line environment. So go ahead and launch Git Bash. And if you are on a different platform, well let's give everyone a second to confirm either through the chat or through some other method that they are able to launch Git. So I'm just going to take a pause.  And hopefully you've had a chance with the preflight work to install a functional Git environment, but you'd interact with that through the terminal application that is already installed on all Macs. So it's either available through the applications inside the utilities folder or you can use Spotlight, the little magnifying glass up in the menu bar to just search for terminal and it will show up as a part of the first search result. We have confirmation from two attendees that they are good. Okay, great. And of course, if you're using Linux, any flavor of Linux, you should just be able to open your terminal. And so now we're moving on to there's a bunch of tutorials because of the different ways we teach this sometimes. If you're following along through the Coffee and Code repository, we're actually moving on to this 0.02.a GitHub tutorial, which is what we're going to be working through next. And so everyone's installed Git, everyone's got it open. The first time you use it and you go to make a commit, if you haven't configured the username and the email address, like we saw in those examples of names and comments being attached to commits, if you haven't set that up, Git is going to ask you to do that. And so it's a good practice.  So feel free to type along. We're going to type in to do this configuration. It's git config space dash dash. We're making a global configuration change, which again, we only have to do this once because it's global. And there's a user object and we're going to set the name property, so that's user.name. And then in quotes, you just want to put your name. And so that one time where you see that some commits in our repository were made by Data Rescue Albuquerque. At that time, I had switched my name because of what I was doing from John Wheeler to Data Rescue Albuquerque. And once you get that, hit Enter. And if it runs without any errors, there won't be any output. The next thing we want to do is set up our email address that will be associated with the changes that we make to a repository. And so that's the same as before, git config space dash dash global user.email. And I'm going to put in my UNM email address, jwheel01 at unm.edu. That wouldn't work. There are many, many other options, global options that can be configured for your environment. If you want to know more, if you're familiar with working in a command line environment, you can always type in git config dash dash help for more information about the options related to the config command. And that did not work. So that should have worked. And I'm going to have to look into why it didn't. But without lingering over it right now, we will move on to check out the various configurations in your system. You can type in git config space dash dash list. And I'm going to reduce my font size here a little bit. And so now we can see all of these options that have been, most of these are default options in terms of the git configuration. I didn't change any of these except for the ones that we've seen with username John Wheeler, email jwheel01 at unm.edu. But all of this information is maintained, like I said globally, so you only have to add it once. If you're working in a command line and you have a lot of noise on your screen like I do, there's a handy command called clear that you can type in that will get your prompt back up to the top of the screen. And I see quite a bit of activity in the chat. John, we had a question but Carl just answered it in the chat. Okay. Yeah, I was about to say, please feel free to jump in with a question. And so now the last thing I'm going to cover before tossing it over to Carl is one of the things I said a few times the term I used was a repository, right? And so a repository is essentially from the standpoint of an object, a repository is basically a directory where all of the files and all of the folders within subdirectories and files within that directory are tracked as part of a version control history, right? And so we have to be careful about where we initialize repositories. And so let's go ahead and whichever directory or space that you're in your computer, we're not going to go to desktop or anything because I found out last week that can cause issues with Apple users. Let's go ahead and make a directory using the makedir command, makedir space, and we're just going to call this git underscore demo. Try to avoid spaces and directory names. Then we're going to go into that directory. We're going to change into that directory using the cd command. So cd space, git underscore demo. People's command line prompts. A lot of that is configuration or platform-specific, so you may not see the path of your context. As I am here, yours may or may not be color-coded. That's all fine. This is just the way my system was set up basically by default. And so if we look at this directory, so we can use the command pwd printworking directory, which will show us, again, the path from the root of our file system to where we are. We're in the git demo directory. And if we use another command called ls, that's for list, basically, ls will list the contents of a directory, right? And we see that there's nothing here. If I use lsa with an a flag to list all, we see these little hands that the system creates. The single dot is a reference to the current directory, and the double dot is a reference to the parent directory. And again, that's something that we cover in our command line tutorials. But basically, either way we look at this, we can see that there's no content here. There's nothing in this directory. So I'm going to clear. And so this is not yet a repository. If we want to make this into a repository, we use the init command for initializing a repository. And so that is git space init. Now, as a result, you'll see, again, this is something that's platform and configuration dependent. My directory now shows me that I'm on the master branch. So that's one indication I have that that initialization command was successful. Another way we can verify that, if we come back to that ls space-a command, which is for showing all, we now see that there is a directory. It's a hidden directory because any directory that starts with a dot like this and the name of the directory will be hidden from normal view. This hidden directory is the git directory, and it is in that directory that all of those history and all of the changes in the commits and the various snapshots, that's where all that gets recorded. And when you start pushing changes and pulling changes from one copy of a repository to another, it's the maintenance of that history data and the history information in that git directory that's where a lot of the power under the hood is coming from in terms of this version control system. So I will pause for questions, and then I will keep my screen up in case anybody wants me to redo a particular command. But other than that, we'll just make sure everybody's following along, and if there's no questions, we can kick it over to Carl. And apparently I stopped doing this right now. Great. Okay, so we can move forward and I will share my screen. And for some strange reason that leave meeting, shiny red leave meeting button always proves an irresistible temptation when I'm in the process of sharing a screen. And I always have to not click on it. And I always have to click on it. So I always have to click on it. Sometimes I will fail to resist that temptation. So what we're going to do now is. Continue to work through, work through. What is a common workflow? As you're working on your system, and you are creating files, modifying files, creating new directories, reorganizing your content, of identifying when you want to actually then take the changes that you've made and essentially add them to a snapshot of the state of your repository. Yes. Carl, we have a question from Elarisa. Whatever I do, will it be applied to your GitHub website, github.com forward slash unmrd? No, not automatically, and we'll actually talk about that later in what I'm going to be presenting as you first have to create an explicit connection between the repository that you're managing on your local computer. You have to create a connection between that and a repository that you may be managing in GitHub or in another cloud-based service like as an example. Here at UNM, our library also manages a platform called Lobogit that is based on the open source GitLab platform. But that's a good question because Git is actually a set of tools and capabilities that you can completely use just on your own local computer. You don't have to have it connected to GitHub or another cloud-based service. That having been said, there are a lot of benefits for having it linked with one of those cloud services as John was describing earlier, especially when it comes to either just working on multiple computers for yourself or especially when collaborating with others as it makes it much more straightforward to share the state of the repository with other users. But no, you need to go through explicit steps to first link your local repository to GitHub. And then you actually need to execute commands. And we'll see examples of to actually push the local changes that you've committed to that remote repository. So when we're talking about the workflow, the key thing to keep in mind is that you can be continuously editing the content of your computer. And only when you hit a milestone that you want to actually create a snapshot, a view of the state of your repository at a particular point in time, do you actually execute these commands? And so one of the things that you can do, and this is something we do often when you're in that repository that you've created, you can use a get status command to essentially examine the state of your repository. And in this case, I'm a little bit ahead of you because I was actually running through some of this material last night. And actually, let me just do this. I will create myself a nice clean repository. So I'm just going to very quickly redo what you just did. So I'm creating a new repository, in this case, in my desktop, by creating a directory, changing into that directory. And then initializing that directory as a get repository. So it's basically that simple three step sequence of commands that allows you to create a new directory that then can be used as a get repository. So if I type get status, we can see that my shiny new repository has, I'm in the default master branch. That's what this message here is saying. It's saying since this is a new repository that I haven't executed any commits into yet, there is essentially no history yet. And I've done nothing in this directory that would warrant going through the steps that I'm going to highlight here. So we're now ready to start doing something in our repository, creating some content that we want to manage. And what we're going to do first is actually just create an empty markdown file. As John mentioned, markdown is one particular syntax that you can use for creating ASCII text files that can then be converted into formatted content, and GitHub can even render that in a formatted way. So a really easy way from the command prompt to create a new empty file is to use the touch command. So it's just touch space and the name of the file that I want to create. So I can just type readme.md for markdown. And since it doesn't give me any feedback, that's actually a good sign because any feedback I would have received here would have been an error message. So in the absence of that, I can assume that that file was created. But as John was showing earlier, I can use an ls command to see that my previously empty folder now contains a file called readme.md. And now I can do a get status. Since I am in a repository that has been initialized, I can do a get status inside this folder. And it's now telling me, you know, what I saw earlier in terms of what branch I'm in and the number of commits that I have. But now I have this additional message telling me that there is this untracked file, readme.markdown. Meaning that this file is totally new to our repository. It has never seen this file before through being added or committed to the repository. And this highlights essentially the first step that you go through whenever you add or modify a file in your repository. So what we're going to do now is actually add some content to this file before we go through the rest of our process. And one thing to keep in mind here is that get in really in all senses can be thought of as an available capability that can run in the background on your computer. And you only need to go in and start issuing get commands when you're wanting to do repository related activities like adding modified files to your history through commits. So what I can do here is I can use a text editor inside my terminal. In this case, I'll use nano and I can type in nano readme.md and that's going to open up this text file for for editing. But just as an as an example. So I can exit nano. I could just as easily go into my, let me change screens here. I can go into my file navigator. Here I'm working on a Mac. So you're, if you're working on a Windows machine, you may see something different, but I'm going to navigate to my desktop where that folder that I created is. And here's this demo to repo folder. And I could just as easily open this up in my favorite graphical text editor. And here I have this empty file. And I can start typing text into it just as easily as if I was using a command line editor. So the thing to keep in mind here is that while you may be using a command line environment for interacting with your Git repository, you can still be using all of your other tools to interact with in terms of the creation and organization and editing of that content in the repository. So I can now just type in some text in markdown. So, so I've now made some changes to this and I can save those changes. And I can minimize my window here so I can go back to my command line here. And if I do, Carl, we have a, we have a question. Yes. Question from Derek. How do I exit GNU nano? So, so yes, nano is, is a commonly installed command line text editor. But you might your, your environment and John, maybe you can provide an insight in terms of what a recommended editor would be for windows, either through the git bash or pre installed in windows that just worked well for you. As I typed carrot X and nothing happened. It looks like John doesn't have sound. I have sound. Sorry. Yeah. There we go. So it's in nano where you see that that up arrow, that is actually a little shorthand for the control button. Right? So you just want to type to exit nano, just type control, hold the control key down and then Oh, we'll save the file if you edit any text to it. And then once it's done with that, you can hit the control button with the X button. And that will actually close the file out. Right. And if you're impatient, like I am, you can just hold down the control and hit X. And I'll prompt you. If you and ask you if you want to save the file that you've been editing as a part of the exit process. And Carl to answer your question for using a text editor in a windows environment in the shell. I prefer nano greatly. I love the fact that it has the commands down at the bottom of the screen. So thank you. Okay. Great. Great. Okay. So we now have this modified file and I can actually run nano. Read me. Md again in my command prompt. And you can see that it actually is now reflecting those changes that I made in the file through my graphical user interface. So you can actually go back and forth and use, you know, pretty much all the tools that you're disposal to interact with the content that you're creating. I just did a control X to exit out of nano. And since I hadn't made any changes, it didn't ask. It didn't ask me to, if I wanted to save any changes. But so far, while we have, if I do a get status again, we still have this untracked file, though we've now added content to it. As far as get is concerned, it's not paying any attention to it. So the first critical commands that we, command that we need to work with is called get add. And with get add, what we do is we base it on the, what we do is we, we basically are telling get to now start paying attention to a particular file. If it's newly created, or if that file has been modified since the last snapshot was taken of the repository, that it should essentially keep track of that particular state of the file for the next time that, that the state of the repository is committed when the next time a snapshot is taken and written into the history. So you have a number of options with get add. And the, and John's experience earlier with the get status, dash dash help or get, was it get config dash dash help. That's going to vary from system to system where it actually works for me, but it depends on what components of the software were installed when it was set up. And I apologize. It worked for me too. But on windows, it opens up the help in a web browser. Which is why I didn't see it. So just as an illustration, if I do get add dash dash help. At the command prompt. It brings up a detailed description of all of the options. For the get add command. We're going to focus on a very simple. Variant of two variants of the get add command. So I just hit Q to exit that help screen to get back to the command prompt. That proves a significant barrier. As it doesn't actually say that anywhere. You have to know that that's the way to exit back to the command prompt. And a lot of people get stuck there. So. The most targeted way to use get add. Is to just specify the name of the file that you want to add. To the set of tracked files. That will be included in the next commit. So if I type in get space, add space, read me. And this is where I can also take advantage of another. Very helpful feature of the command prompt. Is what's called tab completion. I just typed a typed in enough of the beginning. Of the name of the file that I wanted to add. So in this case, I just essentially typed in like. REA. And when I hit tab. Since there was only one file that started with that name. It actually automatically completed it for me. So I didn't have to type in the whole name. So when I type get add and the name of the file. What it's doing is it's now saying. Get, keep track of this file. And include it in the next commit that I create. Now, if I do a get status. We see something different. Where previously we saw that we had untracked files. We now see that we have changes ready to be committed. And the list of files that are going to be committed. And in this case, it's also telling us that it's a new file. But so far, what we've only done is we've essentially. Marked that particular file to be included in the next commit. We haven't actually taken that into account. We've actually taken that into account. And we've actually taken that into account. And we've already marked that particular file to be included in the next commit. We haven't actually taken that snapshot yet. We take that snapshot. Using another command and get called commit.  We can give it a one line command or, you know, and again, it's another command that has a lot of options. So I can do again, get commit help. And bring up the man page and you can see all sorts of different options. We're again going to focus on the most basic use of it, which is essentially a one line. Approach to running get commit, which is where we type in get space commit. We add dash M. Because we want to include a message. This is how you can write a note to your future self or to your collaborators. About what this commit includes. What, what is, um, what is the, the reason for committing this particular set of files. And in this case, I will, I will say, um, added. And modified. Read me. Um, Mark down and with that short commit message, I can hit return. And it gives me some feedback saying that one file was changed. There were three insertions because essentially you had that heading line, a blank line, and that line with some text. And then we're, we're good to go. Yeah. And have a look at how we're actually doing it in the background. Just type in a, yeah. And then we're gonna go to just typing in get status. And in this case, what it's telling me is that I'm still on my master branch, but even more importantly, there is nothing to commit. The working tree is clean, meaning that essentially all of. The modifications that have been made. In the repository folder. been committed there and there have been no changes since then. If I had some new files that I had added but that I had created but not added using the get add command they would still show up here as uncommitted changes. So this is a way that you can always get information about essentially what content you have in your folder and what its status is. So John was a few minutes ago showing the differences between files. We can also do that from the command prompt. And what I want to do here is I'm going to go back over to my graphical editor but again I could do it right in nano and I can add some more text and even more text because apparently I'm not feeling terribly creative today. And I can save that so now I've saved that that those changes to the readme file and I can see now that I have a modified file before before we had done our first committed that file this was showing up as new not modified but since git is aware of this file now it recognizes when a tracked file is different from the version that was in the previous commit. So we can use a the git diff command to actually see what the differences are between the current contents of our repository and the previous previously committed contents. And I can just type git diff and it provides this initially somewhat cryptic output at the beginning of the output is it's essentially showing you what the long form of the command is that's being compared and then it's showing some additional sort of diagnostics and information and it's showing essentially which files are being compared and some additional statistics about the types of changes that were made but the real meat of this is down in this is in the rest of this output where we can see between the the current let's call it a working version of the document that I saved and the previously committed version we have essentially modified this by adding these additional lines and in this case it's treating the even that line that was there as deleted and then re-added because we added a new line at the end of that so we modified even that line of text and when you're doing these diffs it is primarily focused on lines of text and any changes in those lines so we can see here that the output of that command just like we were seeing that in GitHub what we can then do is repeat that process we went through before of and this is very much sort of a wash rinse repeat process that you'll find yourself doing over and over again as you're continuing to work with content in your repository and you want to take snapshots of it as you're doing your doing your work so we can do another get add because we've now made changes and since we've made changes to that read me file we're now saying to add the changes to that file to our next commit so it's the same command that serves two different functions you're either adding a file that has never been managed in git before and so it's then going to start tracking it and adding and tracking it in the history or you're get you're adding a modified file where you're going to add those changes to the history you use git add to do both and I'm going to then provide the name of the file that I want to add and you can do multiple add commands so you can be very specific about what files you're adding to your next commit and in this case I'm doing git add read me in return but again that's just basically told get what we want to include in our next commit it actually doesn't happen that can that snapshot through the commit doesn't happen until I do do a git commit dash m again and then a quoted message that I want to add related to the file or files that are have been modified or added as a part of this commit so we can say added more important text to read me one of the key things with these commit messages is you typically want to keep them short and there are options for providing much more detailed information about a commit as a an additional comment that is in addition to the short commit message and that's so if you just do a git commit without this dash m and this quoted string your environment should actually open up a text editor where you can type in on the first line of the blank document it provides the short commit message that you want to provide then if you hit return a couple of times you could provide even a short dissertation on what the details are of your reasoning for that commit but at the very least you're required to add some sort of commit message that is included in the history so after we did that get commit we can do another git status and we can now see that we don't have any outstanding modifications in in our system so something else that John showed in the github environment was a way to look essentially at the history of commits that have been made from the from the command prompt you can do that by using the git log command so if I type git log and like all of these others that it has a lot of options and by now I would I would expect that you've probably figured out that that's just typing in typing in help if your system has that has that installed but in this case I'm just going to do git log and it's going to show me essentially the history of commits that have been made including this long identifier that is a unique identifier for every commit that's made in this case it's also indicating that this is the head of the master branch meaning that it is the most recent commit it is it is it is by default the one that the history is being built on top of as a part at working within our repository it's providing information about who made the commit when it was made and then the commit message that was provided at that time and we see also that earlier commit and its identifier and that information as well so this is a way where you can in your current environment be able to look at the history of commits that were made on your system but of course one of the other powerful things that you can do is you can compare commits this is what John was was alluding to earlier and you do that through reference to these identifiers because each one of these is essentially a name that's been generated for that commit but fortunately we don't have to necessarily type in or provide the full length of this long identifier we can actually provide a short version of that and we'll see an example of that right now so if we want to see the changes between two different states of our of our repository I can do git diff just like we did before and you'll remember that what we did was by default our our diff command was against the most recent commit but what if we wanted to dig back a little bit further in time we could actually specify that first commit and I can specify that as a part of the this git diff command and in my terminal environment I can just highlight and copy the first in this case I've got was at nine characters or so a reasonable number of characters in that identifier at the beginning of the name of that particular commit and then I can paste that into the end of my git diff command so in this case I'm saying I want you to compare the current content of my my repository modifications and all with that other version that previous version and if I hit return I'm now seeing the the comparison between my my current state of my repository and that specific identified snapshot of the repository from the past and that's a way where you can do that from your current commit or a state of your repository to a previous historic commit you can also use it as John was describing earlier where it's not obvious in the github environment how to do that you can do it between different arbitrary commits that have been made in the history as well so this is a very powerful way to dig into and sort of excavate the changes that have been made in your repository through time and even between specific spans of time that are beyond your current state of the repository so finally we want to get to github as we mentioned in response to that question that came up earlier in terms of how does the the relationship between github and your local git repository work how does that work and I'm I just want to check in is is is everything working well okay so far do we have any questions no questions right now so I'll erase that have you had a chance to set up your github account yet as a part of the pre okay great that that's great news because that's a critical first step in being able to connect your local repository to github so I'm going to now go past our instructions that are in the in the guide for how to set up your your repository and what we're going to do is first now create a repository in your github account and we do that I'm going to change over to my browser here let's see let me find the right window and where did github there is their github is put this in another window okay so here is my my github account and what I want to do is to create a github repository that I can then connect to my local repository so now if you've already created your account you should be something like this once you've logged in and what we're going to do is create a new repository by just clicking on this new repository button right here and you're going to be asked for the name of the repository that you want to create so I'll just call this repository demo 2-repo but you can name it whatever you would like you can then add a description to it and in this case by default repositories are public but you can create a private repository if you want to have control over who would otherwise see your see your repository and be able to interact with it and in this case we're going to leave the the box to initialize this repository unchecked and we're just going to create the repository another workflow that is sometimes used is to create an empty repository in github and even initialize it using one of these options and then clone that repository to your local computer that takes care of this connection process that we're going to go through but in this case we're working from the premise that you have a local repository that you want to bring into the collaboration environment of github so we're going to create this repository but we're not going to initialize it with any content which is what these checkboxes do it tells us it's creating the repository and then it provides some information about different ways to essentially set this repository up in either linking it to the desktop github app if that's what you're using or creating a new repository at the command line that is going to be connected to this or in this case we're going to be going through this process that they describe here is pushing an existing repository from the command line so this is a good reminder of this process that we're going to go through right now so now that this repository exists one thing that I'm going to want to do is I'm going to want to copy this link and you'll see that this link is the same for each of these because yes would you mind going up to the top and showing people the different options between HTTPS and SSH oh sure yes HTTPS option thank you yes so so yes when you are initially creating the connection between github repository and your local repository you have to define essentially how the information is going to be exchanged between those repositories and github provides two different what are called protocols there's essentially the secure web transfer protocol HTTPS for the hypertext transfer protocol which powers you know the the web you know when you're accessing any content through your web browser that's frequently nearly all the time through either HTTP or the secure version of HTTP which is HTTPS you also can use another secure protocol called secure shell or SSH which typically takes a little bit more configuration to be able to set up the necessary what are called credentials on your local computer and in github to streamline this secure communication between your computer and github systems and that's why we typically default to using HTTPS unless there is a compelling reason to use SSH so to do that you make sure that this box for HTTPS is checked and you can also see that is reflected in the name of the link that is provided here if I had chosen SSH you can see it's it's providing this different information which is used to set up an SSH connection but again we're going to use HTTPS and we want to copy this link because we're going to use it as we set up the connection between our local repository and the remote github repository and that's where we use a another git command called git remote and since we're wanting to add a remote connection we're going to use the git remote ad and we want to give this remote connection essentially a name so we're going to call this origin and then finally we paste in that URL that we copied from github this is the information that git needs to save for itself the the connection endpoint in github to communicate with so once I've entered that information I didn't get any error messages so we're looking good but we can verify that essentially our remote settings by typing in git remote just like we typed in for our ad but instead of ad we're going to dash v which prints out basically the remote connection information that is currently set up for this repository and it set it up when we when we issued that ad command to both fetch content from that repository but also push content to that repository so that achieved our our goal here of being able to define the connection with that remote repository in a way that it would allow allow us to essentially have bi-directional interaction with that with that remote repository named origin now that we've established that that connection we can now push our current the current state of our repository to that remote that remote repository in github and that is simply a git push with some additional options and I have to confess this is where I'm lazy because the default for git push is to push to a destination called origin and to automatically push the master branch so I often and I'm in a bad habit of just typing git push where the more complete version of this command is git push origin which corresponds to the specific destination that we want to push to and master the name of the branch that we want to push to so this is this is the more complete unambiguous version of the git push command that it's good to get into a habit of using as opposed to my bad habit of only typing in git push because I'm lazy so if I do this what we're doing is we're then basically sending to the the github repository that we have linked to our local repository the full state of our our local repository and if I go back to github if I refresh our view now since we've now essentially pushed content into the repository and it's been initialized I now see essentially the information about the content of the repository including all the commits that have been made all the files including that really great readme file and I can now interact with or potentially use github as a source to be able to set up other instances of git on other computers if I wanted to work on multiple systems I do that quite a bit as I find myself working on my computer in my office on campus on my computer here at home on my laptop and I can have a copy of that repository on all three of those and I use github as the hub for synchronizing and exchanging the current state of my repositories between those three systems so in that case I'm essentially collaborating with myself so one last thing I want to illustrate and this is something that I will simulate by editing content inside the github interface which you can do but it's not very elegant or powerful is that you can edit to a limited extent files inside github itself so in this case I've you see I basically have this readme file and if I click on it it brings up my view of it and I can actually edit it here in github and it brings up just a very primitive text editor and I can say you know something like so I've added now perhaps too much text I can add a commit a message so this is my commit message and then I can say I want to commit changes so now I have content in github that I don't have in my local repository and this is where I can issue one last command that we're going to talk about today which is get pull which is as you might expect going to pull the current state of the repository from that remote repository in github so if I do my get pull and again this is where my lazy habit comes in where I can just issue get pull and it's going to use that default origin and default branch of master or I can type in the full command and not be and be explicit about where I want to pull from origin and what branch I want to pull master into my local repository if I do that I then get some messages from the front from as a result of that command as essentially I have ordered my and just FYI Carl we're coming up on 1 3rd you've got about 2 minutes left yep and this was actually my last command in my last example but this is basically showing the output of that command and all the actions that that took place in terms of the the objects that are exchanged the changes that were made which particular files were modified and what branches were involved in the exchange so this is essentially the diagnostic information for that exchange the one thing I'll add is that this is sort of a nice smooth exchange that happens and this is something we cover in our more advanced tutorials where there are ways to then deal with issues where maybe changes have been made on both sides at the origin and the local version and how to reconcile those changes get is pretty smart at being able to do that but there are tools and strategies for being able to reconcile those changes so with that I think we're done outstanding you guys rock thank you so much for presenting today I wanted go ahead John did you have something to say before I close this out I just said thank you awesome so once again I want to thank you for this informative and comprehensive training on github speaking as someone with very little experience with this platform you you made it as easy as possible to understand and very accessible so thank you again for being so generous with your time and before I want to before we sign off I want to again thank my partner in crime miss Isis Sirna and join us again next March for Claus Danielson's presentation on the 24th at noon have a wonderful day everybody. Thanks for joining in there. Bye.


Hey everyone, it's Eric Johnson and in this video, what we're going to discuss, we want to talk about staying on the ground. It's so, so important. So why is it so critical to stay on the ground when you throw? It's a pretty simple concept. It's a basic concept of science, right? I have friction. If I'm on the ground and I push against something, I'm going to be pushing against it. I've got the connect chain and I'm forcing or I'm forcing pressure against it. If I come off the ground, I'm going to have no friction and ball is now or the discus is going to be pushing back on me. So here's the thing. I do come across, I stumble across things because everything I do is throwing and I see these videos and I see these videos where people are working all the stuff where they're working up into the air. They're either teaching to jump or they're working on one leg or they're doing all these crazy things. The bottom line is you've got to stay on the ground. Did I make that clear? You can't be up in the air when you're trying to throw. It just defies physics. Sorry. It's not my opinion. It's just how it works. You can work against the ground and come off the ground at a certain point, but you have to work the ground properly. Come off the ground too soon and you're doing drills that teach you to come up in the air. It's a recipe for disaster. So here's what we're doing. One of the things is we see some drills and people are teaching too much elevation. They're teaching one-legged stuff. Now listen, I do some one-legged throws, but here's how we do a one-legged throw. We work that position. We focus on the transfer from our pillar five and six. So when we do heavy weighted stuff, we're working how to create this angle and we're working how to come down to the ground. Kind of staying up in the air is counterintuitive. I understand there's some, the train of thought and I understand why sometimes drills are being taught, especially kind of this type of drill, but when you throw, if you actually do this in a real throw, it's going to be a recipe for disaster. So one of the things, again, when I create these videos, I like to make sure that I'm really clarifying. Some drills are made for very advanced athletes, super intuitive athletes, because they're going to be working on a lot of high level stuff. A lot of these types of drills that you may come across or encounter where you're working off the ground or partially on the ground, i.e. one foot on the ground, those are not necessarily good for most. So here's my tip for the day. When you look at throws, let's take a look at some of a few throwers right now. Best women's discus throw in the world? Sandra Prokowicz. She stays on the ground.  One of my favorite all time throwers is Robert Harding, non-reverser, works the ground. Look at Gerd Cantor. So let's look at reversing discus throwers. When we look at somebody like Gerd Cantor, look at how long he stays on the ground during delivery. Boom. And he comes off. It's a thing of beauty. He works the ground a long time. If you look at the current best throwers in the world, Frederick Dockers, if you're looking at Guz Diaz, all these reversing throwers have a very low amount of time up in the air and they stay on the ground a long time through the delivery. Now let's take a look at some men's shot put. Now if we're looking at somebody like Tom Walsh, his PR is in his 22 plus big meter throws compared to like three years ago when he was thrown in the only 70 feet before he started throwing like 74 feet. But the biggest difference is he started working that ground a little longer. Ryan Krauser is probably one of the best at really working the ground. The time, look at, look at as we look through delivery. Look at the position of his block, look at the position of his delivery leg. Very little time off the ground and that right foot as it comes through on his reverse very low to the ground. Same thing you're going to see. Look at Durell Hill. He just had probably one of the greatest series in the history of the sport at the Diamond League Final, the IAAF Diamond League Final. Look at what he did. More measured throws over 22 meters and two toe files at 22 plus meters, 2240 on the day. Huge day, 73.5. Look at the time. He's spent so much time working the ground. That's the key. The more time you're on the ground, the more time you can apply force to the implement. Whether that's the shot or whether that's the discus, we're going to be able to spend more time, more time. We're getting that hip. We're applying pressure. We're accelerating the implement through the delivery and that's the key. As soon as you start to elevate, that starts to come down. That's why in one of our recent videos, we just posted up the drill down. Simple drill to teach throws how to work the ground. Here's my tip. Stay on the ground. Understand why you've got to stay on the ground because you can generate more speed and force. Understand that a lot of those one-legged drills, they get passed around and people come up with stuff. I'm telling you, it's just not productive. Do drills that mimic the throw. Stay on the ground. Teach athletes. If you're a thrower, learn how to work the ground properly, the sequence. That's again why we have the throwing chain reaction system. That's why we throw these videos up because we want to help clear up confusion. There's so much information out there. That's a great thing and sometimes there's too much and you don't know if you're new and you're coming across videos and I've said this before, you may not know what's good and what's not good. So that's what we want to make sure that we pay attention to. So any rate, hopefully like that. How about if we go give the subscribe a little tip check, be sure to like comment. Thanks for watching and see you in the next video.