So, topic of today is accessibility and I will take the freedom to introduce this A aspect of the FAIR principles. So for the agenda for today, we will start again with some definitions and roles. Then there will be the topic on version control and project management with Git,

with some focus on GitHub and then we will do a coffee break and continue with Git, have lunch and in the afternoon there will be an accessible lesson and with what the meaning of comprehensible

code is and with some function in Python and R. So, starting data to be accessible. Data and software to be accessible, what does that mean? In the FAIR principles, we have again four core sentences here, starting with A1, metadata

and data are retrievable by the identifier, we had this topic covered yesterday, using a standardized communications protocol. Again, here is the focus on the machine readability of also the accessible point of the FAIR principles.

So what does this mean? Standardized protocol, the protocol itself is more clearly specified, so the requirement here is to be open and free and universally implementable.

This can mean a couple of things, we will come to that and it's important primarily I would say for repository administrators, administrators of digital services and so on. The protocol should allow for an authentication and authorization procedure where necessary.

So for example, when we are talking about sensitive data, about embargoed data with restricted access or something like that, this comes particularly into play. For A2, the FAIR principles in A2 emphasize that metadata should remain accessible even

when the data are no longer available. What does that mean? It can happen and it happens a lot actually with scientific journals, that articles have to be taken down because of wrong data use, because the meaning has been misinterpreted

by the authors or there were just some major mistakes in the publication. So those takedown notices or retraction notes are quite often used and they happen across

all journals, I would say across all disciplines, so there are no exceptions. We are still humans and we still tend to make mistakes and some of those mistakes also tend to be sadly intentional. So there are retractions throughout the year but still when we talk about good scientific

practice, we should also care about the point that even if there was some wrong information published that we still can't put this wrong information into context. So if there's a takedown note, usually the journals tend to say, okay, why the paper

was retracted, who the original authors were and what was the context of this paper because it can be that it has been cited and reused in other papers of course already. So also the other authors of the follow-up papers, they need to be informed what has

happened and that a certain part of the research done was not as it should be. So this point actually is crucial and here they say it should not only be the case for

classical academic publications but also for data publications and other kind of publications of digital objects as well. So those are the main points of the accessibility issue and what does that mean for an institution

and for administrative repository. In the terms of the protocols, it means that there should be as little access barriers as necessary but of course you need to have user accounts for the publication process.

So you need to be free to also, if you have to publish for example embargoed data first that is embargoed for maybe one year because of your institutional policy or something

like that, it should be able to support this. The metadata contains contact information and responsibility information, again this is crucial in terms there is also for provenance and in order to be sure and to trust the authors

that published this digital information but also in the case of maybe take down messages or something like that. Open communication protocols should be supported by the repositories, there are some listed

here, the standard ones, they can even be more in use but it should be emphasized that they are open protocols and standardized protocols. Some warning signs when you use a repository maybe if they have a special up or down load

tool that uses different kinds of communication protocols, it can be useful like with SFTP for example if you have large volumes of data to be up or downloaded. And this is a point that is not that well implemented in many digital repositories,

even the big ones, it is the term of the tombstone page, sometimes there is just a short take down message of the data set but without a reason stated and with no metadata

information whatsoever displayed. So this development is changing slowly and the UI agencies are working towards this to again to change that but here the journals and the big publishers, they are ahead of the research data community I would say.

So they have here also decades of experience with those retractions and the research data community is just starting to develop such a system and it's not harmonized yet.

So that's something to keep in mind and if ever there is the case that you have to retract digital content, please bear in mind it could have been reused by other academics and to offer them the information why it has been retracted and that you are the point

of contact for them. And also the repositories usually should have an exit strategy in place in terms of accessibility, so if one repository has to shut down its services, there should be

an exit strategy for others to take over. And this should be clearly stated in the terms and conditions you will find with any repository service. So I know terms and conditions, usually one does not have the time to look at it or

to look at it in any detail but it's worth a look when you trust your scientific work including your data to a repository to have a quick look here if there is something like an exit strategy or what happens to your data if the repository service has

to be shut down. So this is worth considering. As a scientist, again, you should think about that the data access should be programmatically

whenever possible, that means using web services, for example R packages, Python models and so on. Sometimes also in order to get a data set, especially when it is embargoed, it's necessary to still write an email and state your intent and what you plan to do with the data, so

it's a trust issue among academia essentially, but I think most authors are open to those requests. Also in the case of sensitive data, so some of the institutions which host sensitive

data, they have explicit application procedures where you clearly have to state what your research intent is, where you come from, your institution, what your background is and so on and so forth, but this is also due to the national law, for example.

Of course, if granted, then you should check if a secure access, of course, is possible using, for example, password manager and metadata, they are essential, so again, also

for the accessibility of a data set, when you submit it, you should always check that the metadata is complete and it can really, in this case, when we use the data set it can really help you to plan your own research and see how the others have done it,

what they did, what they stated in the metadata, for example, to ensure web usability of the data and you should really feel confident enough to also, if you have a repository, for example, a local repository at your institution, to request this kind of features

from the repository administrators at your local institute. In Germany, we have the case that many universities tend, in the last couple of years, started to set up their own local repository infrastructures and, of course, as a scientist there you may be encouraged to use them,

but then we would again encourage you to really check what kind of features the repository systems offer and if they are, in your terms, they are not good enough, so ask them directly for

improvement, which is essential for your field of study. Yes, now we will continue with the version control and Katrin will take over. Thanks. Okay, as I already said yesterday that the fair data principles cannot 100% be applied to software and this is the first case where

we will be interpreting a little bit and the accessibility principle here we will interpret as follows. So you saw this just now, just to put it besides the version control systems that are currently, well, Git is obviously the most popular, but there's also Mercurial,

which has a similar concept and Subversion, it's a bit outdated by now maybe, but still in use. So check, check, check, these protocols are open, free and universally implementable. The platforms that, for example, use Git and GitLab and GitHub, of course, they have access

control, login and features like that. On GitHub, we also can reiterate a little bit about the findability principle here because there's topics which are basically keywords for a repository and it is possible then to have global lists, for example, of all repositories that are tagged

with, I think, microbiology we had in the example yesterday, right? So this makes things discoverable. About the tombstone pages here, we have to be honest again, the scientifically specialized repositories are a bit better here, but if, for example, an organization

decides to close their GitHub account or even a whole repository infrastructure like Microsoft CodePlex or Google's own code.google.com was closed. They are kind of in an archive mode, so you can still find stuff, but you are with these platforms at the mercy of the companies

behind them and they may not be super interested in preservation as the scientists and the librarians are. So we will also see what happens with GitHub, which has been bought by Microsoft or will be bought in the course of this year. I would not be worried too much, to be honest, but yeah, we don't know.

Recap from yesterday. So a little bit, we talked about how in version control systems, the identifiers are generated intrinsically from the content of a repository and that is something a little bit different than the so-called minted PIDs like Doi, which we also did in this demo

with Zenodo. So just keep it in mind. And again, reminder, there's a workshop tomorrow for software preservation. If you're interested in this topic, please keep an eye on the Software Sustainability Institute's blog. So now, since you are all here voluntarily, I don't

think I have to convince you why you should be using version control, but I think one very nice example is simply that you can substitute the tree of life, as you maybe know, there's some murky origins and there's a eukaryotes and there's a prokaryotes and so on. You can

equate this a little bit with a project. So it's a messy beginning usually, and then you generate all kinds of digital artifacts like protocols and you collect your data and you build graphics from this data and you put the graphics onto posters and into papers and your maybe notes and observations again feed back into your protocol and you improve this protocol. So all of this

is happening on a time scale and it of course would be important and interesting to document a project and version control is one way to do it. We choose Git here because it is the most popular one and in particular through the platforms of GitHub and GitLab. There's also

Bitbucket and several more. GitHub is starting as well, so there's just network effects everywhere. It's a social network of like-minded people, of developers where a lot of information can be shared and especially learning can happen all the time from even strangers.

Then maybe if you talk with your colleagues, if you try maybe to convince them to use version control you may encounter the argument, the counter argument, yeah but I don't want to publish my code, I want to keep it on my own. That's not the point here. So version control system makes it easier to publish things but it doesn't enforce it. So as we will see, you can work

locally, you don't have to upload your stuff. Even if you upload your stuff you can have private repositories, that's not the point. But if you do publish your code and the documentation for your project, there's simply an opportunity to gain collaborators and to just collect useful feedback. So here's one example from the

Better Scientific Software blog where some project, it doesn't matter, stated that we had the requests for Windows support for so long but none of our team really knew how to do it. But then finally we uploaded it to GitHub and some person who didn't know how to port a

software from, I don't know, Mac or Linux to Windows, they just did it in a weekend. So there are people out there who are interested in your project and if they are, they can be convinced or motivated to just help with stuff that you do not know. Also remember the little Venn diagrams with the knowledge of each one. There's just people out

there who can help and if you don't offer them the opportunity, they may not or they will not. If you offer them the opportunity, they may do it. And for the Bug Diver example which we will also use a bit today, I even have to state this for myself, I developed it privately for several months and within that time I got scooped. I mean somebody else delivered also a

client for this web service in Python. So if this person maybe would have seen my project, they could have saved themselves a lot of work and we could have maybe collaborated. I don't know if this person is interested in R or knows R but stuff like this happens all the time and

prevented. Then also one really, really important argument for version control is the way it structures your workflow. You have these things on GitHub and GitLab that are called pull requests and merge requests. It's just a fearless way to work. You cannot break anything.

You cannot break anything. You can implement the changes that you want to do on a separate branch. We will see what this is later. It's essentially a safe environment for your own work. You can upload that, you can review it and only if it works you can merge it back into the

main branch and continue working with this as if it were a natural part of the project all the time. And if it doesn't work, you just let the branch rot and delete it and no harm done. And of course on the platforms especially, there's huge automation potential. There are bots who can do rear view, who can take over code formatting and all the little annoying

things really have been automated already in some kind of bot or external service or probably will be soon because this is really a symbiotic relationship here between the platforms, the users, even some companies of course to just drive software development to more effective and

more efficient territories. And in the end, because the platforms also offer web hosting, issue tracking, project management tools, a Git repository especially if it is uploaded somewhere and public can be your single source of truth for a project. And this is maybe not super obvious

but I mean you all know probably the many communication channels that you have. You use email, some of you have a Twitter account, then there's some kind of chat system probably in a project and all of this proliferation of different communication channels also has a huge

cost in terms of cognition. Stuff gets lost, emails don't get read. It's just in many cases too much and therefore saying we have the code here, we have the issues here, we have the documentation here, everything in one place can be really really useful for everybody. About the project's evolution, there's three aspects I think to be considered here. So first of all,

you can have like a time machine-like view into your project, you can hop back into any point of time in the past. It's maybe a buzzword but 3D, you know it from virtual

reality and stuff, it's always a buzzword but here you can really have a 3D view into your projects. On the one hand, you have your normal view like a Windows Explorer, files and folders as I mentioned at this old time points as well but also the current version of course. Then there's a so-called history view where just the commits in the version control project

are chronologically listed so you can read up on what has been happening and maybe why it has been happening. And there's also a so-called blame view where you can see a file and that is annotated line by line with the commit message of the last commit.

Where's the visualization coming? There's also a microscope-like view because you can always look into a single commit and see exactly what has been changed character by character exact and as I mentioned the time machine-like view as well. So here's the 3D box as I mentioned before, you have on top the regular file and folder view, you have the history view

here on the right and you have the blame view where you can see an annotated version of your file. So depending on what you need to find out about your project or about somebody else's project which you may be joining and need to get up to speed and understand how they arrived at the point where they are now, this can be quite useful and yeah the microscope view

into this whole thing is also quite useful. So these are the images I would like to stick in your mind. And yeah accessibility here of course also means understandability and in your own project this in many cases will mean just your future self.

We all forget what happened even a few weeks ago in some cases you may need to explain to collaborators what you have been doing, get them up to speed, some of you are maybe supervising students and of course reviewers also when you want to publish something they would also be an audience for understanding your project better. And to do that we have the software feature in

Git and in all version control systems usually of a so-called commit message and this should always explain mostly the why. Why are you changing stuff? Because it is always recorded what exactly you're changing. You don't need to explain to people that you are adding this file

or that you are removing this file. That is obvious. This as I said will go into this log view or blame view and yeah we can have a look. Again I don't want to make too much advertisement but there I'm pretty confident for this project that I can explain what has been happening.

So we're looking at the log view now or the history view in GitHub and yeah you remember from yesterday we got doi. I fixed some formatting mistakes here. I reverted a commit which we can have a look at. That had the effect of finally after a long while adding all

the manual pages to this project. So we're not going to look at them in detail but as you can see here I'm removing one ignore rule and then all of the nice help files are included. We will learn on Thursday how to generate these help files for our packages. So now we're basically

in the microscope view. We're looking into one specific commit and we're back here at the history view and of course being new to a project not all of this will make immediate

sense but going through it step by step will help to understand what has been going on. All right and in the blame view we're going to have a look in detail as well. I should probably increase this a little bit. So here on the right you have some code. This is our code and here on the left whenever you're interested like why did they do it like this? This code looks

beautiful or it looks shitty. What is the reason for doing that? And here it would be refactoring to enable retrieve search results and we can look exactly at this commit what I did there. So for example introducing a new argument which we will learn about later today introducing this

if else suggestion which is depending on this argument. So no matter whether you can read our code very well or not this is the way to start understanding things if you are interested.

And this even works for huge projects like Git for Excel for Git itself for example the source code is also version in GitHub and of course there are thousands of people working on it. 10,000 of commits it's 13 years old after all and even there you could just go in see why somebody has changed something and see exactly what they changed. And then the pull and merge

request from the workflow I showed earlier that then just mostly needs to state what is being changed in a summary because the person who is reviewing the pull requests will see a list and okay I have time to review for example a proofreading pull request. The diffs itself as

you saw just now they should always be logically encapsulated and there shouldn't be stuff in it that doesn't belong to the main point of the change and that's called atomic so that each of the commits can also be reverted without breaking anything else without introducing a fixed typo for

example again. So whatever task you have in a project it should always be completed it should be put into a commit or several maybe and committing also works across several files which we will see later as well. So this is also helpful for everybody. So for example if you are

then the commit message should also be just proofread for example or if you are implementing both the code for a feature and the test these can be put together as well. We will learn how

adding tests works in both Python and R on Wednesday probably and Thursday. So and all of this boils down to the accessibility features of Git in terms of the fair principles not in terms of technical accessibility they boil down to that it's a communication channel it is a documentation system it is a communication channel and you should always

consider how would you explain to a collaborator for example in the elevator you know this elevator pitch you have two minutes to explain something or three that's similar here so just in a few words why you did something the summary of what you did are the important things here

in order to for them to understand it and if they can read it from the commit messages for example then they will not have to email you and will not have to call you maybe so it's also a communication avoidance system when when necessary when when it's not necessary to to

discuss things. Issue tracking and project management as well I already mentioned this briefly it can be your living plan it's a community workspace as well the issue tracker can be used for all of these kinds of discussion and also in this board-like view which you have

both on GitHub and GitLab you can also do time management and stuff like this. The issue is here the let's say data structure or the thing that you are using it can be really anything from just basic ideas noting them down quickly and just leaving them to mature maybe

to problem reports for users just questions for help anything really don't be shy don't try to spread these different things across different systems that can be a lot of overload. Thanks to markdown you have all these nice formatting options like you can have task lists

on a platform you can usually mention somebody so they get notified we saw this linking from commits to issues as well that works within issues already so you can just say oh this is related to this and so on and all of these project management things are there as well so if you have some kind of different topics within your project you can use labels you can assign

it to different people well usually yourself if you're working in a project and you can have milestones which are basically deadlines there's a date associated to it you can say okay these tasks i have to do by this milestone and so on and yeah the peer reviewing and the

pool merge request workflow is also extremely useful for teaching each other if you are in a team maybe not now but probably at some point later when you have to have to write your own grants have to write i have to complete your own projects together with collaborators you are a team and you need to learn from each other and you need to teach each other about important

things oh yeah that's the closing keywords that we mentioned yesterday just fix a hashtag issue number will automate something some things for you so the issue tracking is really lightweight on the platforms probably much better than in a wiki because in a wiki usually have

pages the pages are dynamic yes but a bullet list of ideas it's kind of dead because you cannot insert other people's comments easily it's it gets crowded really really quickly and emailing ideas and discussion points back and forth always has a disadvantage of the quotes usually being below

so effectively you need to read it from bottom to top and that's unnatural in an issue tracker it's always original posts on the top and then downwards and i also want to mention the point here that version control is not restricted to software source code so it is of course

optimized for that but you can put large non-text files in it there's a system called lfs large file storage so if you have some kind of files like this it is possible to version control as well there's even video editing solutions that rely on it and what could be larger than video editing the text documents obviously lattice and markdown are very popular

there and if your problem for example is if the problem you need to solve is that you often have to work without internet connection maybe in the field for example and if you need to work asynchronously with other people then this can be an alternative to these tools like

google drive and etherpad and stuff like that because they solve the problem by simply syncing all the time i'm not saying you should leave these tools at the wayside but if you can't work when you're offline then git is a good alternative

and there you basically only have to overcome this one limitation of git that it's optimized for a line based text files which is software source code but when you're writing maybe a paper or something then you usually have paragraphs which several sentences in one line technically and as

you can see here a solution would be to simply break it off after 80 characters after 100 characters then the diffs can stay small and atomic as i mentioned before so that's a little annoyance but i'm pretty sure that sooner or later some solutions to that will be found currently

if you want to version control a text it is still a thing and yeah one of these or many of these tools that under that work on top of git are for example overleaf the lattesch editor online editor there's also git book which some of our colleagues in the open science lab have already used there's also authoria for paper writing generally and pen flip which also is as far as

optimized for pros for writers non-technical writers so this workflow of version control and the ideas of that are spreading more and more and yeah i'm looking forward to for example

seeing laws and regulations written like that there's an unofficial project in germany that scrapes the changes in the law and puts them into a git repository um but why aren't people doing this in the first place yeah then the law says oh in this sentence this word is being changed great so i have to now take the other book of the law and look

up what the word is i mean um it's a bit weird it's a bit weird so any kind of document that is collaboratively written and that is updated over time and not just uh the type of fixes so these updates have to be meaningful and in all of these cases a version

control system is really useful the first demo would be to go through a contribution workflow and while we are doing that we're going to draw down um where conceptually um we are so we're working on github now so we are in the cloud

but the same would be true for gitlab um and what we are going to try is to look just for some typo misspelled word and we'll just send a pull request to that repository with the correct spelling which is maybe a bit stupid but i think it is something that no project owner

would would reject reject so maybe within a few hours maybe faster maybe in a few days all of you should have a merged pull request an accepted contribution so as you can see um we could not perform this code search for analysis so i'm hoping that no spanish or other

language has this in the correct spelling so the first thing we need to do is to log into a github account oh i know what is coming i have to have two-factor authentication on

the reason for this is um yeah github is github account is a reasonably important thing and two-factor authentication is as you know from your bank probably the mobile tan um that protects your account a little bit in case your password should become compromised

so after you have logged into github you can perform the code search and the link i used already listed lists it the the search results by recency so all of these misspellings um are pretty recent so there's a good chance that when

we fix it the people are still active in this project um i would suggest the following now because there are so many please starting here page one page two page three everybody just go to a different page of search results here so that everybody is surely picking

a unique target basically so just count through here see how you're sitting and just go to a different page than the first one um shouldn't be too far in the past but please put up the

green stickies here when everybody has found a search result that looks like an actual typo where they will want to make a contribution and fix this typo okay so here at the very bottom there the different uh search result pages just go into it a little bit

and then the here the link i shared it in the in the document or you can just search for the

misspellings in the github search bar so please if you do not see this results page put up the red sticky and if you have found one repository with this misspelling that you want to do put up the greenish yellow sticky um if if you see something like this like the main page

of your profile you can just type the spelling error here in the search bar and yeah now the um also our other instructors will hop around and go to the people with the red stickies to help them if if you see a repository results then you can switch here

to the code after you have logged in and instead of best match you should switch to

recently indexed so that we see the active projects up top we can also restrict the

search here to text files or markdown files so we would we will try to uh only send pull requests against documentation text not against actual code because we here this is an example we cannot really be sure is this actually a misspelling or is this variable intentionally

named like this so um please please find a repository with some txt file or with a markdown file where it actually seems like a genuine misspelling so i will also go somewhere

into it so let's say maybe i will go to page 35 is anybody on page 35 i hope not okay okay

so yeah i will i will go to this one we perform a cell and i lose this and i'm going to check in lingui whether that's actually a misspelling yes analysis so so remember we are all the time now here first in the repository of

some person some organization somebody we don't know it's good has anybody picked a file that they want to edit and it's something different so that's why i asked you to go

onto different pages um yeah no just on to directly to the file where the misspelling is so do you have such a results list okay what do you see do you have that's it exactly and

then you can even restrict it here to to text or markdown or html maybe to filter out code

okay again please put up a red sticky if you don't see something like this so you're in some project some folder and some file open okay so if you do not see something like this

in a file please put up a red sticky because i'm going to continue now so the github web interface already has this edit symbol here on the right this little pen um but it's grayed it tells us you cannot do anything now you must be on a branch so and the git branches are what

i mentioned earlier they are the safe environments for uh for people to work on to not get into conflict with other people's work and the branches are arranged in the so-called tree and this is uh this button here and we are now specifically at some of this uh this this time

point level that i mentioned before so this hash is a part of the git hash and that's the identifier for a certain time point and at such a time point we can only look we can't do anything therefore we must switch to an actual branch which in most cases will be called the

branch or if you have for example picked some kind of web project it can also be gh pages or gh page so click on this button please and just select the master branch or a gh page branch

and if either of the branch names is not present at all please put up a red sticky i'm going to switch to master and this behavior is specifically to github so if you go from the search results list into a file you will be on such a time point view you will not be on a

branch automatically i don't know what the purpose of this is it's yeah just one step we have to do in order to unlock this edit option okay so i'm going to do this and now we start going into the git workflow it tells us this the edit button has this label fork this project

and edit this file because we cannot edit the file in someone's repository there's a red sticky there what is going wrong okay thanks okay um is that maybe def development or something that

looks very general gh pages okay great so we are going to fork this project now this takes only half a second um so now we are working in our fork which will not really see

in the web interface but there's a blue note here which explains this a little bit so now we are here we are in a copy of this person's repository in a fork and the editor is already open so i'm just going to search for the same spelling mistake here in the editor

and i'm going to edit it analysis like this okay i'm going to search again if it's maybe there twice no

and control f so you just go into this editor file and press control f while you do the same thing i'm looking for some other type of so i'm just scrolling through it because if we're here

we might as well fix two typos so if you found the typo and fixed it please put up the yellow

sticky the green sticky and if there's some kind of problem the red one please okay and then after you've done it please click on the preview button here and now and then search with control f for the

now corrected version of your word and you will see that there's a little preview showing exactly this is one of the atomic small logical diffs that i mentioned before it should be just one word

crossed out in red deleted and the green one is the addition our correction of course so again red sticky if you don't see something like this please so then we scroll to the very

bottom of this preview because now we need to finish our proposition and as you maybe know from graphical git clients you have these two lines there's in gray already the suggestion of a git commit message updating this file but as i mentioned it's obvious that we are updating

this file so these kinds of commit messages are not super helpful so we will just tell the person that this fixes a typo no sorry not this fixes a typo but fix typo so the the grammar here's the what is the base case in grammar it's the

shit sorry infinitive the infinitive exactly thank you i think we don't need to have an optional extended description so this is just fixed typo okay so

and then we're going to click propose file change yes that is interesting then in that case

interesting yeah then then you must for some reason be in a repository that you have right access to ah okay so if you good that's a good point so we let github do this forking for us now in the background automatically if you clicked actually the fork button in the repository

then uh the button here will be commit changes so but it's the same thing um let's click it propose file change and now github will do the reverse thing it will start

a comparison which is the precursor to a pull or a merge request which we will send back now the comparison is the precursor to this workflow instance of um of this workflow object of a pull or merge request you see here that the base fork that's the repository of the

other person it has the person's username and we are on the branch master okay i'm going to explain this to the end and our fork this is with my username here or with your username and we are on this fork we are not on the master branch but github automatically

so master branch it automatically created a patch one branch probably so again it is the master branch would already be a copy of the repository here it would already be a safe environment

but um for every kind of work setting up a different branch is generally a good idea so github automatically created patch one for us so if you don't see such a thing with a comparison and again with your um correction here please put up a red sticky we have our summary here we have added one commit here's the commit message one file was changed and here on the very right

you see again such a hash and the hashes as i mentioned are the intrinsic identifiers they are computed from i think the timestamp the content of the diff here the um the email address

of the person who's committing so several information are being hashed together and importantly also the hash from the previous commit so there's a mathematically verifiable change of commits one on top of each other and stuff in the middle cannot be changed without this

checksum the hash being changed as well and that's the reason why the identifiers are here are called intrinsic because they can be computed from the actual content of the repository and as long as the content doesn't change they don't change either and therefore in turn

can be used as identifiers to address a specific commit for example it's like a maybe a chain of pearls yeah they are tied together and if one of the elements is broken not by natural law but by somebody changing it forcibly for example then the whole chain falls apart um as well so

okay then please click pre-create pull request and it will suggest a title for the pull request here we will just leave fixed typo and maybe we can leave a nice comment um see diff for example

in my opinion this usually or in my experience this usually works because i mean we're not pointing out somebody's mistake we're helping them fix this so um and also here's a nice feature which you will as far as i know only see on one of the

git platforms i'm not sure about gitlab but github now allows you to grant access rights to this person here to your fork specifically this branch so because they now have to decide oh will we include the suggestion or not um you could argue that they should be allowed to

improve your suggestion if it would be a bit more complicated of course than here the type of fix um in this case we leave it at that and complete our contribution suggestion here by clicking create pull request and now we are back here and we have one pull

probably one pull request maybe there's a different number here for the project that you are contributing to and again we have the different view here we have the commit history which is pretty short in this case we have the diff view this would be the summary of all changes that

you are proposing in this pull request and what conrad and me both mentioned that there's lots of external services to add some kind of automation bots this is in github it's called here checks so you have you can have automatic code review

any kind of stuff so it's um it will be a bit more relevant maybe on thursday and wednesday when we talk about testing so automatic testing bots can also be included so if you maybe in the conversation view see some kind of yellow or green or red bubble here that some kind of checks

are running or have been run or have failed or have succeeded then this is really good then this repository has already set up some kind of automatic checks which is again this communication avoidance system when it's not necessary it will immediately tell you oh no your contribution doesn't fulfill some kind of requirements maybe some test breaks which should not be the case

here in in case of a typo but if you're contributing code it is really nice to have safety net of the project owners already having set up some automatic tests and then you don't even have to wait for a negative email like oh but you broke our tests no the system can tell you

immediately automate or not immediately takes maybe a few minutes sometimes but automatically that's the point so that's our first round of contribution here we have automatically created a fork some people have manually done that we have edited the fork

on a different branch and we are sending from that branch the pull request to the main repository branch again okay so then let's leave this I hope that for most of you this will be just a matter of maybe a few hours that the person accepts your contribution let's have a look at the

a bit more complicated example and one that is related to the doi system

I switched the link please open it in the same browser that you use for github and we're going to help data carpentry update one of their lessons in this case

we will probably not everybody contribute the same thing but we'll just go through the workflow without in the end clicking the actual pull request button maybe we can have a little I don't know some kind of competition who can do it fastest but that's not the point

so how many people of you know what the current URL of the doi resolver is because that one is outdated the dx.doi is no longer the current resolver who knows it's a bit strange that the doi foundation would change the resolver address

but okay so what we're going to do now is to go through this contribution workflow a bit more manually a bit more step by step and also downloading the repository because there's now

several several files that we would need to edit and we don't want to make three separate commits with fixed typo here fixed typo there fixed typo in the third place we want to have it all in one go and one commit across several files so what we are going to do is now don't jump into one of the files please but go to the repository itself and here we have one of the views here

from the 3d view of course the files and the folders and we could now clone and download it because of course we want to work on our local machine as well I'm just calling it local so we want to um we want to clone stuff now should we do it from this repository who voting who's for

cloning it directly from here nobody okay that's good because that would get us only half of

the way because remember this is somebody's repository you don't have access rights here so of course you could copy it and change whatever you want but you will not be able to back directly so what we need to do is to create this fork manually now um again this only takes a few seconds and now we can use the clone address here

from our own fork so now we are here red sticky please if you don't see something like this okay no it did not because you're still here so you need to click fork

no all right afterwards cool good again please red sticky if you don't see this

okay because is it working okay okay good so and now we are going to jump into the um git bash now please please copy this one here there's this nice little button but you can of

course also use copy yeah forking forking first fork first clone second

i have the fdp placard modified if you want okay um so please everyone open git bash uh for example through the windows uh search

and if you do use a graphical client of course you can follow this example with the graphical client as well as just the call

common denominator here. Yes, I use all of them and they all are good in one aspect and horrible in another. I think GitHub desktop is quite a good compromise between all of the different considerations because GitHub desktop, for example, has the nicest diff view in my opinion, but it has the fewest advanced options. So, Ziyat, what

is the problem? Okay, cool. Okay, so does everyone have the Git bash open somehow? Again? Yeah,

how do I, okay. So, okay, we're not going to get distracted by the website in the background, so please put up a red sticky if you don't see something like this. I'm going to have a look around with the ls command. So I want to, as I mentioned, we want to fork and download.

We have forked it. We want to now clone and download the repository. And in my case, I always do this in the repository Git repos. So I'm going to change directory to that, but it doesn't really matter. You can just do it in whichever directory you are currently

in. And you will be able to delete it afterwards, of course, as well. So it's not going to clutter up your file system. Yes? Then try the search again. There was the one with this one. Right. Okay, good. Yeah, some people have several Git bashes, like with this non-descriptive symbol.

It should be this one with the windows colors. So please open this one. Yes. Okay. Ah, right.

Okay. No, no, you're already there. No problem. That was for the windows guys. Yeah. One, do you, Esma? Okay, good. Yeah, sure. Of course, the, the, the, the Mac, Mac and

Linux users just open a terminal. It's probably not called Git bash for you, but terminal. Okay. Okay. Okay. Almost everybody has, so the clone command as most Git commands just

use exactly that verb. So please type Git clone. And then again in the different operating systems it will be different. So I'm just using the paste function here to insert the URL. And I want to show you one trick. I'm clear this. I want to show you one trick

because you have probably seen up here that, well, it's already a pretty large repository. There's already 900 commits before. And because we are only making a little contribution here,

we do not need to download the entire history. That is the clone default, but with the option minus minus depth in front of the URL, that is important. Depth equals two, for example, we can limit the history that we download and thereby save a lot of

bandwidth in particular, because we are all here in the same wifi downloading this 30 times completely, could be a bit longer than just using here Git clone depth two. Okay. So I wish that this would be the default for Git, but for some reason it is not, but

in so many cases you don't need the entire history and you can always fetch it later if you do need it. So what I'm doing most of the time is just cloning with depth equals two. As you saw, this just takes a few seconds. It was just one and three quarters megabyte. And now if we check with LS, we have this SQL ecology lesson. There it is.

So we're going to change directory again, CD, SQL tab. Please put up a red sticky if downloading didn't work, cloning didn't work, or you cannot change into the directory

that you just cloned. Should I bring it up again after each command? Okay. But you should see all something like this. Okay. Now what happened? We cloned it. So now

we are in a local directory. The branch name here is also printed. So I'm going

to show you. We have downloaded two commits and that's where we are. First thing we will do is we create a branch with the command Git branch, and then just we will call it

fix-typo, for example. So the branch names should also be a bit more descriptive maybe than patch one or patch two. This is just GitHub's standard way, but if the branch name can already express something about what this branch is for, then that's of course

quite useful. Nothing happens. We are still here on GitHub pages, because now we also need to switch to that branch. And that is called a checkout. And you just type

the branch name again. And if you then press okay. Is it download slow or what's happening? Wow. Okay. So, unable to access. Yeah, oh shit. Have you tried the event Wi-Fi?

Okay. Okay. Neither through any room. Oh shit. What do we have here?

Okay. Okay. Okay. Oh, your mileage may vary with custom kernels. Okay.

You don't really need this lesson then, do you? Then no problem. Good. Okay. Unfortunately, we have two downloading issues that seem to be related to the Wi-Fi

or the proxy settings. Oh, sorry. That's unfortunately something we cannot help right away. Yes? I don't see the branch name like you do. Is it because I didn't use it correctly? No, no. That's a different way. The Git Bash on Windows is doing this. The terminal is not. Yeah. If you don't see the branch name, sorry, that's again Windows specific

or Git Bash specific. Okay. Everybody switch to the branch. Okay. Now, who wants to use the editor in the terminal to fix all the spelling mistakes now? Nobody exactly. The

people who did raise their hands, we don't believe you. We are going to use a regular text editor. I think the installation instructions had a long list of different ones. The one I have here is Atom. Atom could maybe be started exactly with this command, Atom

dot, and the dot stands for just this directory. This should work both on Windows and Mac if you have Atom installed. If not, you will probably need to go into the

finder or the explorer and go to the repository, the folder that you now downloaded, and open it with, I don't know, maybe Notepad++. I don't even have Notepad++ here. We assume

that you all know how to open a folder in your favorite editor. Is anybody having problems with this part? Is it okay? The folder that we downloaded, the SQL ecology lesson.

We wanted to update a bunch of DXDOIL links, right? I'm going to go back here

and copy the outdated link, HTTP DXDOIL control C to copy it. In Atom, we're just going to use the find in project. It's control shift F or command shift F so that we don't

have to look up which exact files had this outdated links, but we can just go through the whole project and plow through all of it, search and replace these HTTP DX with HTTPS and no DX. I can't make this bigger, sorry, but I can make the diff bigger in

a moment. I'm going to use the find all option. Control shift. I can't increase

this here, I'm sorry. Is this find all and replace all or however this is called

in the other editor that you are using, is that working? Is that producing some search results and replacement results? If not, please put up a red sticky. We can close Atom because it has done its job. We can also remove the website here, we don't need it

right now, but what we need again is the git bash. One of the most important commands is git status, just what's the status of my repository? As we see here, we are in

a repository. Also in the terminal, in the Mac terminal, it may not be shown by default that you are in a repository, but if you are not, git will tell you that you are not. Git status will say we are on this branch. There are changes that we have not

staged yet. Is anyone aware of what the staging area is? Should I explain a bit? Git sits

on top of your regular folders. In the git context, your normal folder that you can explore is called the working directory. Git will not interfere with that. It will let

you work there with any of the normal programs that you use to edit your files, but what it will set up is a next level, basically, the so-called staging area. Into the staging area, we have to add our changes. GitHub did all of this transparently and automatically.

In GitHub, basically, as soon as you edit, you are automatically here in the staging area, and when you commit, you're automatically copying the changes into the repository itself. On your local machine, there are these three things, your normal directory, the staging

area, and the repository. We will have a look at the repository later, but for now, we have to tell git to add exactly the three files here that you see. You can just use the first letter and then tap, because each of the first letters is unique here in

the file name. We will just add contributors, the extras, guide, always using tap, tap, tap to complete it, and set up MD. Then we will repeat the git status command, because now we will see that changes to be committed are exactly our modified files here.

This little suggestion has been removed. Now we have the stuff in the staging area. The next command is git commit with the minus M option, because, of course, we want to have a git commit message, and fix typos seems to be sufficient. Sorry, it's not

fixed typos. We are updating old doi URLs. Sorry, something like this. Update, we were

in the infinitive form, right? Update old doi URLs. Okay, there's a little summary of our commit, the commit message again, the branch, and the short version of the

commit hash, so the identifier, and a summary how many files are changed, how many insertions or deletions. What is the next thing that we need to do? We need to upload this change

again, and the command to do that, so we have our new commit here, and now we want to push something, and the command there is simply git push. Okay, there were a few

people who did not use git before. For everybody who does not see such a commit summary where it doesn't seem to have worked, we have to use the config option,

and then tap, tap to see all the, oh my god, this is too many. It's core, no, what is it? It is, okay. Can you say what the email and author syntax is? It's global.

User dot, okay, user dot name, and email. Okay, so yeah, some of you have to use

this option. Sorry about this, I forgot because so many have already used it according to the survey. Yeah, okay, so I have it configured, I will not do it here. It doesn't have

to be identical, but the email address should probably be the same, just to be sure. Okay,

when we use the git push option, we should all get some kind of error. Please try it, git push, enter, and the reason is we have created a new branch, and we haven't told git which branch in your local copy corresponds on the server, so there's just

nothing here, but with the option that is given here, or the command git push set upstream, which you can just copy and paste probably. If not, just type it down. You are saying

that the upstream of this branch is on the so-called remote, and these are remotes from the point of view of your local repository, and by convention, the remote that is called

origin is the one that you have write access to, you should have. If we would have cloned directly from the data carpentry repository, our origin would be that one, but you cannot write to this, so the origin doesn't make sense here. You have to make sure that origin

is always the one you have write access to, therefore fork first, clone second. So it's in many cases you will see such a command suggestion in case you have an error that

helps you fix that error. Please put up a red sticky if this long command with the remote name and the branch name that you want to set up on the remote does not work, so there should be like a little upload summary if you use git push minus minus set upstream

origin fixed typo. Please put up a red sticky if you don't see something like this. If you clone from a URL, it will be automatically set as your origin remote. So the workflow

on GitLab would be exactly the same, so you should probably be on a page like this in your fork of the repository. You will not see this yellow thing probably, I'm not sure,

so it should be, do you see it? Maybe, okay. Well, okay, even better. Please put

up a red sticky if uploading didn't work, if pushing didn't work. Yeah, syntax error, check again, compare this to this. There must be no space. Yeah, now you have forgot

the origin. Okay, so uploading worked for everybody now. Okay, then we switch back

to the browser to, yeah, okay. How about there in the corner, did it work? Thanks.

So then some of you are seeing like a yellow banner here with a green, something like this.

So that's a shortcut to create the pull request, but I'm going to go the long way in case anybody is not seeing this yellow banner here. So to create the pull request, we go back to the target repository, go to the pull requests menu and click new pull request.

So the comparison now is a little bit different here. For me, if you have used this yellow

green shortcut, it will probably be already with the base fork and the head fork set to the correct repositories and branches, but I'm going to show you the long way as well. So if you go the manual way, you have to go to the compare across forks option and

in the head fork, choose your own copy with your own username. So you can use this nice filter thing just for your username and then switch to the branch that we uploaded just now. So please red sticky if you don't see this comparison with our commit here.

Okay, Conrad, can you help Giacomo? No, okay, great, great. What is, should I go back

to some step? Okay. Yeah, create the pull request. You can leave the title here and

you probably see some little pop-up here. It looks like this is your first time in this project. This is one of the nice community features of GitHub. If the project you want to contribute to has some kind of guidelines or code of conduct, you will be able to have

a look at it here. So for example, I'm pretty sure I know that the data and software carpentry projects have this. So how to contribute, they explain a bit how this works. You can even send them an email where to contribute. So it's usually a good idea to have a look

through this at the latest at this very moment. So if it would be a larger contribution, it's maybe more economical to read through the contribution guidelines first because they might say, we don't want any. It's unlikely, but in this case, what not to contribute, the carpentry lessons are already pretty full so we cannot just accept more

concepts, more tools, stuff like this. So in some cases you can save yourself a bit of work because not every kind of contribution may be accepted. But updating some old links is usually no problem. Then here, since there's a little template that we can read through,

we are not in an instructor checkout in this case. Please delete the textbook for submitting. We will do this and just, in this case, cdiff would maybe not be super

convincing because we are claiming that the DOI URLs are updated and the justification of this is the DOI handbook. I'm going to put it into the other pad here. So this

is just a little background thing. The reason that they, I don't know the exact reason why they changed it, but in particular they now resolve DOIs securely. So it's over HTTPS so that there's less chance of researchers being spied on what articles they want to download. So this is a reasonable justification so I'm going to just say cdiff and this URL.

So now I'm not going to do this. Somebody can. Yeah, question? Exactly. So yeah, this

would also be a place to put it. So if you knew that one of the issues was talking

about this, so for example, check all links and update to recommended syntax, it's probably not exactly the one we're looking for, so let's just search for DOI here in the issue section. Yeah, there's no issue about DOI in particular, but hey, let's do it. So

somebody has the enhancement suggestion here to, yeah, it's a good point, but it's probably not exactly what we're looking for. It's some kind of internal link syntax

thing from the Carpentries, so we should not directly reference this issue, but we could. So just by using this number here, for example, or the issue number from up here, we could tell the Git platform, here we're back in the comparison, to usually in

our code, have started our work with the updating links based on an issue that told us to do. That's the project management aspect, right, that the issues are some kind

of self-contained tasks that people can pick up, complete, send a pull request and fix the issue by this, but in this case we're not going to do it because it would be a bit confusing, so this is an unsolicited contribution. I don't know how we decide who sends the pull request. I'm not going to do it because I've done too many of these.

I have automated the process. It's a flood of all doilings. Giacomo, you had, I think,

the most troubles with the Git workflow. Do you want to do it? So if you're at this position, just do it, okay? I'm going to just, not yet, okay. Who wants to do it? I'm

going to, yeah, then, okay, again? Okay, just click it. I will close this because we do not want to overload them, but I will then look at your pull request. Ah, two people did it, okay. I would suggest that maybe, because this does not really

reference that issue, it's not exactly the same thing that maybe, Benedict, you should maybe, there's a close button here for you probably and maybe write, oh sorry, duplicate

or something. Yeah, but this issue number is not correct, so technically your system was correct. Pull request in this little competition, sorry. But you can type duplicate

off issue number three, so hashtag 237. It would be clear in your comment, Benedict, when you close it. So in this case, there's kind of a lock, so they have set up a protected

branch so that some project collaborator needs to review it and approve it. We can

quickly have a look at an approved pull request. So I see here, for example, that my typo fix at least has not been commented on or has not been updated in the last hour, but we will look at a larger pull request here. I'll send the link as well in the pad

if you want to have a look at it as well. This will be the lesson we go through in the R lesson and on a few days ago, I proofread it, so the branch was called proofread.

The title of the pull request was various minor improvements, blah, blah, blah. There were several commits in it. Hopefully, yeah, here's some fixed typos as well. De-duplicate some code, rephrasing, linking fairness to the description file, so stuff like this

and Luke was kind enough to use the review feature in GitHub to approve. Remember this GitHub flow graph where there was the section about reviewing and discussion and commenting? So that's, as far as I experience, extremely useful workflow to work asynchronously to

request the review from somebody, maybe, who's the owner of the repository or a collaborator and as you can see, there's labels, there's milestones here. Well, not exactly, there's no exact milestone set, but this is how it looks if somebody approves and if not,

yeah, if not, I think I can show an example where it's not approved. Here, changes requested.

Now if you would be the owner of a repository, to you it would look a little bit different, so the pull request would have these options here that you could set a reviewer, set assignee. If you compare this with the pull request that you sent about the typo, you see these

metadata here, but you cannot set anything, right? In your own repositories, you will be able to use these options. As I mentioned, these are the project management and time

management aspects of the Git platform. It will look similar in GitLab and what's the most powerful thing is in the changes, file changes view here, there is exactly this review changes option. Up here, this is a summary and I can just generally say, yeah, this

looks good, approve or no, please change something, request changes or it can be neutral, just a comment and most importantly, in the diff view from on GitLab and on GitLab as well. You have these options if you go with your mouse to the, I can't probably

follow this right now, but if you go into the lines, you can say exactly here what needs to be changed or this is a good code refactoring, this is a good solution, you can do the comments exactly in place. You probably know this from maybe sending

word files back and forth, it's also possible there to put comments there, PDF as well, but here it is really, really useful and again, you can say, no, it's just a single comment or you can start a review here. I think in summary, I'm trying to find

the point where I request the changes. I only use the summary option here, from the changes review, I typed some comment and it said generally this has to be changed, should be changed. Okay, so now we went through this workflow as well. For most

of the people, this was called master or gh-pages. The gh-pages, by the way, that

is the branch from which GitHub can generate a website for you. I mentioned that Git is not just useful for source code, but also for documentation for papers, for building websites. If you ever need to publish a project page, you can, for example, look it up on

pages.github.com. It's just a few steps to get a project for a repository, for your user, your personal homepage, for example, or an organization. It's all built into GitHub and that's the reason why this branch, in some cases, was called GitHub pages. That's

what the Carpentries are using as well. For example, that would be the fourth dimension actually. For example, the R novice lesson, this is the repository view and if we go to the website, usually indicated with this github.io and then user name or organization

name, then we are on the website that is automatically generated for this project. We will see this on Thursday as well when we go through one of the lessons and in the homework basically that I sent around before, you also probably saw a few of these lesson websites. That's

a nice little benefit, but we're not going to get into it today. We have gone through the workflow twice now, once only on GitHub and once with cloning and pushing from and to your local repository. I'm going to close all this and switch back to the presentations.

We're almost finished. This is just a bit nicer version of this diagram. In particular,

what is often confusing even to me sometimes is what remote is set up. Origin will always be the one from which you clone. You can get the slides, by the way, of course, right? But it's nice if you tweet them right now. Origin will always be the one that you clone

from, but therefore you should always clone from your own fork unless you are invited to a project maybe and have right access, then you can clone directly. There's also some other commands here. If you need to update your local copy with the changes from the main repository, you use fetch and then upstream. That is the other convention.

Upstream is the repository from which you cloned, and this one you have to set up yourself. I think to finish this demo, we can use the command to set up the third leg here basically,

the fetch leg. Let's go to Git Bash again, or the terminal for Mac and Windows users. Everybody still in this SQL ecology lesson? Okay. The command to set this up is git remote

add. We can also have a look at the remotes that are already there with show. Git remote show should only have the origin, and if we type this name again into the command,

we should see the URLs here. With git add, and now we need to get the URL for our

Mac Harpentry SQL. I shouldn't have closed it so quickly, but this is where we started out, where I first asked you whether we can use this URL. Now we can use it for

a specific purpose. Please copy it, insert it into the command here. Git add, no git remote add. See, I make a mistake sometimes as well, quite often actually. Git remote add and the URL of the data carpentry SQL lesson.git. This will add the repository URL,

but there's one item missing. Do you remember what I mentioned about the naming convention?

We need to give the remote a name always, and in this case, because it's the original repository, we will call it upstream by convention. You could call it anything else, but if you stick to this convention that your own fork is origin and the other remote repository

is upstream, we are setting up our local repository to also know about this original repository. I shouldn't call it original maybe, but the foreign repository from ... No,

not exactly. I will come to this in a moment. Okay, did this work for everybody? Okay, then put up a red sticky, please. You use the remote show option again, and now

there should be ... Sure, sure. No, not that one. That's the one that should be

in the git remote add upstream and then the upstream URL. Please, red sticky if you don't see origin and remote here when you use git remote show, and if we use git remote

show upstream, we can even also verify that this is now the other URL here from the data carpentry. We have two remotes now, which our repository, our local repository can see. There was a question now about fetch and pull and push as well. In push, we had

to set the upstream, and there we told our local git that it should push this branch to origin, and we put the branch name there as well. That's unfortunately a third

meaning of upstream because from the view here, your upstream can be called origin or it can actually be called the upstream. The option here is just a little bit stupid, but all of the commands, fetch, push and pull as well, they can be used now with

the remote names. If we wanted to update our local repository, when we added the remote, we now have the option of fetching from the upstream repository, so git fetch upstream

will do that. It's also telling us everything worked, there's some status reports about how much stuff would be fetched. The fetching informed our fork of the stuff

that was here. In this case, it means little because it was so quickly the repository here, I mean our demo was so rather fast that no changes happened here most likely, but if after some time you need to get your local copy up to speed again, you would

need to fetch from the upstream. It's annoying, it's not named very well. Fetching is not physically fetching and downloading the stuff. That is git pull, so fetch is just the first, that's why I mentioned inform. Now your repository knows what changes are here

and if we use git pull, we can download them. Should we do that as well? Fetching is updating the internal catalog of what changes are there which could be downloaded.

Git fetch had an output, didn't it? Git fetch upstream. There should be, ah, then maybe you used it, did you use it twice? Yeah, okay, I can't reproduce this now because

I, ah no, there is, sorry, sorry, sorry. There should be at least once, there should be some kind of output like this with branch names from the remote. If it didn't, then you fetched from origin maybe because then there would be no difference between what you cloned and what you have here and what is there. Please try it again. But set

upstream at that, when we did that, we only had the origin. Git remote, that's verbose,

right? Git remote, oh, nice, good. Okay, then please do not use git remote show, but best always use git remote v. As I said, everybody will be learning something here

even, the instructors. So is everybody seeing something like this? Origin and upstream was two different. The upstream is the foreign one. The last thing we will do before lunch

is having a look at this shallow cloning again. So remember, when we cloned, we used a depth option and therefore when we use git log now, we should only see a few commits.

So our own should be up top and then maybe two or three or maybe four until you reach the end. Is this true for everybody that they just see a few? If you use the arrow down, it should be very quickly at the end. If you use git log, which is the log

view or the history view, it should be really short. So if you scroll down with the arrow, because we used this depth, which the nickname is shallow cloning, because we used this depth before, we can now also unshallow and really download everything. And the option

for that is git fetch dash dash unshallow. So let's just do that and then compare the log to see that actually we have everything. So before it was only a few. Git fetch unshallow should take a little while and now if I scroll down, there's a lot. All 900 commits.

And you can get out of this view, this log view, if there's a colon here still, you can just press Q. Unshallow will download everything. We have in the very beginning,

we used the shallow clone with only two or three or four commits and if you ever need to get the full history, it will just basically lay the foundation of the little

part of the commit history that you cloned, for example, only two commits, then it will download all of the stuff here. So we're still on our branch here, no matter on which branch we are, the history here will be unrolled basically, don't know how

you want to call it. Maybe a good idea to keep this in mind, this thing is from the kitchen, the working triangle. So that's the three things you have to keep in mind, as long as you use the Git hub or GitLab platform only and do the proposed file changes

there or edit your own files there, you're just up here in the cloud, you have only two things to deal with, maybe only one, but if you start working locally, you will have either all three of these things or if you don't contribute but only work on your

own stuff, then you only have the local and your own repository. Actually, you wouldn't have the fork basically, but this one, then you would be writing here. But because so many people said they had not yet collaborated on a project, I wanted to demo this contribution

and collaboration workflow and I mean, the world of open science, that's really recommendable. Should a computer ever delete anything that a person put into it? No. So why is changing something that you have to do? So of course, we always want to have everything changed, especially in a version control system because we can always undo something and yeah,

if I just start deleting some crap, Atom, that's a bit now Atom specific, but in many other editors it will work similarly. There's some kind of symbol usually here, maybe a blue dot, maybe a little asterisk or star that indicates the file has not been

saved yet, but usually whenever we go into a different file, if we switch out to another program, Atom will automatically save it and some other editors as well. Sometimes you can configure it in the option, I would recommend doing it because forgetting to save something and then closing it is super annoying. And even there's often some kind of highlight

that this file now was changed or even here is a little Git panel where we can also do this staging and committing workflow, but there's so many different graphical options that we can't really pick a really good one. Maybe once we could try the lesson

only with Atom and GitHub desktop and not use the command line at all. But yeah, that's something to keep in mind that with the modern workflow tools like Atom or Sublime is another editor, Notepad++ and so on, usually you have autosave. Many modern editors

have, for example, package managers installed where you can install lots of stuff, a mini

map for your files. It's sometimes useful, sometimes not. Where are we going? Where is it? Mini map, mini map. As Konrad said, this is really an all-round tool. If you master one of the text editors, you will have a lot less work in many cases.

But mastering it is some work. If you haven't used any text editor, Atom and GitHub desktop are a good choice of graphical Git client and editor because they work together quite nicely. You can switch from one to the other and back. I can quickly show it maybe.

We have 10 more minutes before lunch. So here in GitHub desktop, which you can, first of all, you can get from desktop.github.com. Ah, where is it?

So here it's for Windows and for Mac and there's a Linux version as well. Then if you install that and set the option to here the external editor Atom, these two things

work together quite nicely and we can look at the repository that we have just edited in the command line, the SQL ecology lesson here. We can add it and then have a look at our commit with the old door URLs in this way as well. So it's just a different

view onto the same information. GitHub.com shift key slash desktop and there through the release thing. Yeah, there's, there's Linux installers. Okay. And I'm not going

to demo GitHub desktop, but if you have not used a graphical client before, it is a good, a good way to start. There is a Git desktop carpentry lesson from the Caltech

library. So if you just search for github.com Caltech library, Git desktop, I'll put it in there.