so, now I have a bit of free time to tinker with my files and stuff

I was rereading the messages about branches

but I am not really getting it

I definitely need to actually try it out

in order to understand

huh, APT is upgrading chromium-browser

I didn't realise I had that package installed at the moment

when I want to test something in Chromium, I install it, do what I wanted to do, then uninstall it again to save disk space

but apparently I forgot to do that

this system must be full of stuff I'm not using by now due to poor housekeeping D:

@Zanna There were sort of multiple conversations going on.

yes

@Zanna Indeed. Do you want my input at this point, or do you just want to try stuff out right now without my further thoughts?

I was a bit confused

Input would be great. I'm not very good at playing around with stuff as a beginner. I like to find some exercises to walk through

Okay. So, run:

git branch

(and show the output, please)

$ git branch
* master

Similarly, you'll see master mention on the most recent (i.e., topmost) commit listed in the output of git log.

master is a branch. So far, is the only branch in your repository.

I've realised that I didn't clean up after renaming that file the other day

All your commits in this repository so far have been on the master branch, but in the output of git log you can see that only the latest one is labeled with the branch name. If you commit again, the new commit will be associated with master in the output of git log.

@Zanna Clean up how?

i.e. I didn't do a commit

Oh.

Well you can and may as well.

git status

and I added some more files too

and show the output?

$ git status
On branch master
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

	new file:   RiceGrains/GreensPomegranatePulao

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	deleted:    RiceGrains/KalePomegranatePulao

Untracked files:
  (use "git add <file>..." to include in what will be committed)

	TO-TEST/AlooKurma
	TO-TEST/BeetrootChutney

And run it after the commit too. (I'm suggesting this in relation to the concept of branches.)

@Zanna You can commit all your changes together or you can separately stage and commit some changes and then others.

@Zanna So you can see that the output of git status says what branch you are on (and that it is master).

I'll try to do that. I think I can do one for renaming (both deletion and creation) and one for both of the new files

@EliahKagan yes :)

Makes sense.

@Zanna If you run git log now (no need to show it) and also after each commit, you'll see what I was talking about where the latest commit in the branch is the one marked with the branch name.

can I edit a previous commit? Like, I am dissatisfied with the message I wrote and I want to elaborate a bit

Yes.

Is it the most recent commit?

@EliahKagan Yes I see that :)

@EliahKagan it is

Excellent. That is the (main) situation where it is reasonable to edit a commit! :)

Run:

git commit --amend

:)

ok, I've fixed it, thanks!

Since you only want to edit the commit message, you should not stage anything before running that. You can, however, actually change files and stage them before running that, to change the actual contents of the commit. You should do that with great care. Although it is sometimes possible to recover the old commit, it is confusing to figure things out that involve it, in all but the simplest cases. When the actual files that go into the commit need to be changed, consider a separate commit.

But the use case you just experienced is a great example of when git commit --amend is often a good idea.

The other thing to keep in mind about it, though, is that if you have pushed the commit to a remote repository, then you should generally not amend it.

(You haven't used any remote repositories yet, so sorry if that's confusing.)

@EliahKagan I can see why that would be confusing

@EliahKagan no not at all. I have some idea what a remote repository is. I figure that is what we are looking at when we look at GitHub and suchlike

Yes.

So, does the output of git status now say

On branch master
nothing to commit, working tree clean

?

yes :)

Cool. You'll notice from the output of git log that the new commit is now the one associated with master.

Sorry I keep harping on that. :)

We think of a branch as being a sequence of commits, you know, a branch.

@EliahKagan no that is helpful! otherwise I won't get the idea properly

But it is actually a label that points to a single commit.

Unlike other such labels, like the hash of the commit (the hex number shown in the output of git log), which commit a branch refers to moves as you make new commits.

a... tip?

Yes, exactly. A branch is really the tip of a chain of commits.

I see, so the tree metaphor is working nicely

The reason it manages to identify the whole chain, and thus behaves in a way that is conceptually branchlike, is that, for whatever commit it currently points to, that commit points to its parent(s), which points to its parent(s), and so forth.

I see that :) :)

As I had mentioned earlier, a commit usually has exactly one parent. But an initial commit has zero, and a commit that results from a merge can and often does have more than one.

The other thing about branches is that you can be on a branch.

In fact usually you will be on a branch, when you use git.

Right now you are on the master branch.

When you're on a branch, and you make a commit, the branch is updated to point to that new commit.

A repository can have more than one branch.

If it couldn't, none of this would be all that interesting. :)

Well, it would be less interesting.

hahaha

Before creating another branch, though, I suggest running:

git reflog

Because you ran git commit --amend, the output of git reflog should show something interesting.

I realise that reflog is probably short for reference log

I think that's right.

but my brain insists on re-flog

as in flog again

that which has already been flogged

:)

git reflog shows a history of what you've done on the current repository.

@EliahKagan the amendment is noted at the top of the list, like an extra commit

It doesn't show every action. It shows actions that make things or that change where you are.

@Zanna Yes, and you'll notice that the old amended commit is still listed there, with its hash.

yes

You can actually use that hash to recover the old commit.

This is what I was referring to when I said, "Although it is sometimes possible to recover the old commit"

Rather than trying that out now, though, I suggest making a new branch.

when would it not be possible to do that?

In practice, a common situation where it would not be possible is that you're not actually even using the same local repository at all, but instead that local repository is gone and you've cloned a new one from a remote to which you never pushed the unamended commit.

However, relog entries are eventually deleted automatically.

I don't remember the default behavior for that. It happens based on age or number of them or both. I haven't yet had a situation where I wanted to find something in the output of git reflog and it wasn't there.

oh

@EliahKagan it's probably doing it judiciously then

You can suppress that behavior entirely, or change it, but I don't remember how.

Yeah, I think so.

You can also manually remove entries from the reflog.

hmm. Why would you want to do that?

Once and entry has been removed from the reflog and nothing else refers to that commit...

...you can still often get it back by its hash!

:)

I have a view through the window in front of me of many branches

:)

what should I call my new branch?

or, what am I going to use it for?

@Zanna In practice I'm not sure. I suppose one might prune entries so the reflog would contain only stuff that's likely to be relevant. Or one might prune entries to cause the data associated with the commits they reference to be deleted (though as I alluded to, it's not quite that simple).

ok, I guess I don't need to think about that much at this stage :)

@Zanna Often a branch other than master is used for a new feature. Something you plan on eventually merging into master eventually. I should perhaps have suggested that you put the TO-TEST files on their own branch. Actually, you can still do that, and if they were added in the most recent commit, it's quite easy. You can branch from where you are now, then revert the commit on master. You can work on them on the second branch, then merge back to master later.

@Zanna Well, I think it's good you asked because it touches on what to do if you really want to get rid of data because something sensitive went into a local repo that has remotes, but has not yet been pushed to any remotes, and you want to never accidentally push it no matter what.

that seems important to know

The practical answer is usually that you should make sure everything you want to keep is pushed to the remove, then delete and reclone the repository.

hmm. The idea of the TO-TEST files being a branch sounds probably like a brilliant way for me to manage my stuff

@EliahKagan Once entries are out of the reflog and the commits they refer to are not referenced by anything currently accessible, they are eligible for automatic garbage collection. You can force this to happen... though it's harder than it seems to ensure a commit is referenced and that a full collection occurs, and harder in particular than the instructions one might find on the web would suggest.

You may be interested in git help gc on that.

Anyway, if you're curious if something is still accessible and you have its hash, you can try accessing it by its hash (details on that later).

I'd like to show you how to use the reflog to recover stuff, but I think it's conceptually better and clearer to try it out first with a deleted branch than with an amended commit.

So... onto branching! :)

@Zanna So, you could reset the current commit, make a new branch, and then commit the new files "for the first time" on the new branch. I advise against this, however. It's usually better to revert than reset and I don't think this one of the exceptions to that. Furthermore, having the new files in the history of the master branch will make it less scary when we delete the new branch in order to try recovering it. :)

Assuming you decide to do that.

since I don't really know yet how I'll end up using this to manage my files, I can just make a branch for new stuff that will get added later without changing anything I have already done

Instead, decide what branch name you want, and then run git branch with that new name as the argument.

@Zanna I'm not sure if that's a question but the answer is yes. :)

Though you may want separate branches for separate new things. That's up to you.

You could name your branch something that has to do with the recipes that are going on it.

Or you could name it testing or something.

I called it New

Okay.

Capitalized branch names are unusual but acceptable. :)

Anyway, it's quite easy to rename a local branch later.

When you make a branch with git branch ... (where ... is the branch name), it makes the branch from wherever you currently are, and it does not check out the branch, which is to say that you are not yet on the branch.

I encourage you to run git log again. This should show both master and New associated with the latest (first shown) commit.

The output of git status should still show that you're on the master branch.

To move to your new branch New, run:

git checkout New

Then git status should show that you are on the new branch.

Before you either run git reset or git revert on the master branch -- and actually I'm thinking that in this situation I was wrong and it may be better for you to use reset, I'll describe the difference in more detail soon and you can decide -- do you have any other changes you'd like to make and commit to the New branch.

Switched to branch 'New'

Since the more common way to use a feature branch is to branch and then make changes, I think it would be illuminating if you were to make changes on the New branch. Idk if you have anything you want to do on it, though.

I suspect I will actually delete everything, restore from backup, rearrange my directories and start over when we are finished. But maybe I will resist that temptation and instead work through shifting everything around the way I want through this process. That would probably be more difficult and better. Thinking that I can throw everything away and start again will probably stop me being excessively cautious though

You can even throw everything away and start again with git if you want. :)

@EliahKagan I want to add another file

@EliahKagan awesome

@Zanna Go ahead!

If you're on the New branch, then git commit will commit your changes to that branch. The New branch will refer to that new commit, and the master branch will be unchanged.

You will be able to see this in the output of git log.

When that's done, please let me know, and I'll tell you about your options for making the tip of the master branch not have TO-TEST/AlooKurma and TO-TEST/BeetrootChutney.

done

So, since you're on the New branch, if you run git diff master it has the same effect a running git diff master New.

@EliahKagan yes, I can see that, the (master) label is attached to the previous commit, but the latest one has the label (HEAD -> New)

@EliahKagan That should show the changes from the master branch, which should just be the new file, because the master branch currently has two of the test files.

@EliahKagan ahh yes, making sense :)

Now check out the master branch and run git log.

now I don't see the commit I made on the New branch

Right. If you look in the working tree, the new files should also be absent, and if you had made changes to any files, those changes would be undone by the action of checkout out the master branch that does not have them.

But since they're committed to the repository, you can get them back but checking out the branch that has them.

If you like, run git checkout New and then git checkout master again to see the changes.

(Which I encourage you to do, to get comfortable with checking out branches and the changes that happen in your working tree when you do.)

so here I'm at the tip of the original shoot. I can't see the new bit that branched off. From the new shoot that branched off, I can see everything on the parent branch too. But if I add some new commit here, I won't see that from the tip of the new bit. It's like I can only look downwards

Right, git log shows you the history up to the current commit. Each commit knows about its parent commits. Making a new commit does not change existing commits, so commits don't know about their children.

I see :)

However, you can tell git log where you want to look from by passing it an argument, and that doesn't have to be anyplace that would currently appear in the output of git log with no arguments (i.e., it doesn't have to be a commit that is "visible").

To try that out, make sure master is checked out, but run git log feature instead of git log.

great, that's really good to know!

so I can easily choose a viewpoint without actually going there

Also, you can make git log show you all commits, even if there is no commit (no "vantage point") from which they can all be seen at once. To do this, pass the --all option.

git log --all

Suppose you have branches that have diverged and never been merged. Then running git log starting from the latest commit of either branch won't show commits on the other. But git log --all will still show them. (It may also show stuff you don't care about, stuff from other branches, and so forth.)

@EliahKagan whose output at the moment is the same as the output of git log from New, but only because that's the only branch that has grown so far

@Zanna Yes, and most git commands work this way. For example, you can branch from somewhere other than what's currently checked out by passing a second argument to git branch.

It's just particularly useful with git log.

@Zanna It's because the master branch has not grown past the New branch.

yes

If you committed on the master branch, that would not be visible with git log with no arguments or options, run while New is checked out.

yes, I am getting that

Like other git commands, but also especially useful for git log, the argument you pass to tell it where you want it to operate from does not have to be a branch name. For example, it can be a hash.

Try running git log with the hash of some commit that isn't the tip of any branch.

You can get such a hash from... git log. :)

Also, anywhere that calls for a hash, you can provide a prefix of the hash, so long as the prefix is unambiguous, which is to say that it's a unique prefix and it doesn't get confused with something that isn't a prefix at all (like if you have a branch abc then the hash prefix abc won't do even if it's correct and unique).

nice !

so I see the commit whose hash I typed a bit of at the top, and then all its parents below

Its ancestors, yes.

oh haha yes

That's not at all specific to git log, but something useful that is specific to git log is that you can tell it to display only up to some number of commits. You would do this in the same way you'd tell head or tail how many lines you want to see. All the following work and are equivalent:

git log -2
git log -n2
git log -n 2

I tried that and it worked

I can see why I would want to do that

You can also specify commits relative to their children with ^ or ~ notation.

although rather than everything being printed down to the bottom, I notice that the output of git log is getting paged nicely

For example, master^ refers to the commit before master.

master^^ refers to the commit before that.

master~9 refers to the commit that was nine commits before master.

ooh!

Now that you have multiple branches and are comfortable moving between them I should explain what HEAD means. You see this in the output of git log.

yes

HEAD is just wherever you are.

it's me

haha

And you can use it in places the name of a commit is required.

You can use it as either argument to git diff, for example.

You can also use ^ and ~ notation with it. For example, it is often useful to write HEAD^ to indicate the parent of the commit you're currently at. HEAD~9 is nine commits ago.

got it :) very useful

Note that ^ and ~ with HEAD work the same way as they do with any other name that identifies a commit. Like, if you check out a branch, HEAD is the tip of that branch, and HEAD^ is the commit before that. HEAD^ is not the tip of whatever branch you were on before you checked out this branch. HEAD has nothing to do with the history of where you've been, except in the trivial sense that it has to do with the current part of that history (i.e., it's where you are now).

It's like the head of a tape player

Hmm, I wonder if that's why it's called that.

I don't know.

which maybe tells us about the age of git's creators

If you do want to know about where you've been recently, git reflog will help with that.

Well, if that is what the meaning is from.

I don't know what data structures git uses under the hood, but a chain of commits is, as you've observed, a tree structure, and in the usual case where a commit has one parent, it has a list topology. head is the traditional name for the current node in a singly linked list. (Since each node in a singly linked list is the first node of a sublist; in the traditional terminology, the first node is the head and the entire rest of the list is the tail.)

so, nothing to do with casettes :)

Well, this is just another guess about the naming.

Anyway, having done some moving around, I suggest running git reflog to see the log of that.

@EliahKagan oh, I hadn't realised that

Also, you can try out stuff like -3, -n 3, etc., with git reflog, which also supports it.

@EliahKagan nice, I can see all the moves

@Zanna Yeah, git reflog shows operations that make things or that move from one place to another. I think that's a reasonably accurate way to state what goes into the reflog.

$ git reflog -3
7a40b43 (HEAD -> master) HEAD@{0}: checkout: moving from New to master
eab2d9c (New) HEAD@{1}: checkout: moving from master to New
7a40b43 (HEAD -> master) HEAD@{2}: checkout: moving from New to master

just dancing around

Now, you won't often do this, and some people think one should really never do it (to get stuff done--I don't think they'd object to trying it out). But I feel that this is the right time to mention, and to encourage you to try out, how you can actually check things out that aren't branches.

ok

One reason I recommend trying this is that it illustrates the subtle difference between a branch and the commit that branch refers to.

If you pass an argument to git checkout that doesn't name a branch but does identify a commit, it checks out that commit.

I think I'm not quite getting what checking out actually is, so I think this will help me with that too

Oh.

Can you describe what doesn't altogether make sense?

A commit is a snapshot of a working tree, together with some metadata like commit messages (and knowledge of its parent(s) if any). When you check out a commit, it modifies the actual contents of your working tree to restore it to the way it was at that commit (with some exceptions, relating to files that are ignored or otherwise untracked).

The usual way to check out a commit is to check out a branch, which restores the state at the commit at the tip of that branch and also causes subsequent commits to be on that branch.

I'm not sure if that makes sense.

I think I just need practice. I am thinking of checking out like moving from one branch to another. But earlier checking out rescued files that were deleted. So understanding how checking out affects the actual files that are in the repository seems important

So, like, if you're on the master branch, you don't have the changes that were made on the New branch (unless they've been merged into master or something). Those new files don't exist and any changes made to existing files aren't there. Inspecting the files in your repository will show that those changes aren't there.

are there some words missing in that last sentence?

A misspelling ("so" should've been "show"). Fixed now.

They are, however, kept track of by git. (Specifically, information about them is stored in files in the .git subdirectory at the root of the repository.)

so they are safe

Yes. Running git checkout New moves from the master branch to the New branch and applies those changes to the actual files in the repository directory. It also unapplies changes that were made outside the New branch.

@EliahKagan yes, that's an illuminating explanation!

@Zanna Yes, moving between branches changes which files exist as well as the contents of those files. The first time you did it, there were no such changes, because master and New started out at the same commit. After all, New was created from master, and at that time no new commits were made on it.

Another way to put it is that the changes that are shown by git diff A B, where A and B are (to simplify, let's say) branches, are the changes that get made to the actual files in the repository directory on disk (the working tree) when A is the currently checked out branch and you run git checkout B.

This is why it's useful to have feature branches. Changes you make on the feature branch (in this case, the New branch) don't affect the master branch. If you then want them on the master branch, you have to perform an action (usually a merge) to get them there.

@EliahKagan ok, that's really helpful, since earlier I looked at that and it made sense

People tend to find checking out commits (rather than branches) weird. You may have been right that doing so will make git checkout clearer in general, but I figured it was worth taking a bit of time to describe it better first.

But if you haven't tried that yet, I do encourage you to do so.

@EliahKagan I definitely see why that would be useful even with these files that have nothing to do with writing software. Seems useful for writing almost any kind of text :)

@EliahKagan so it tells me my head fell off

@Zanna Well, the other thing about branches is that if you're using a remote then you can't avoid the concept because your local main branch (usually master) and its corresponding remote branch (usually origin/master) are technically separate branches, its often useful to diff them to see the contents of what hasn't been pushed, pulling from the remote actually involves a merge, and so forth.

@Zanna Yes. And it talks about stuff you can do in the "detached head" state.

yes

Personally, the only things I would suggest doing in that state are inspecting files, running git diff, and making a new branch from the commit. Some people say that even that is excessive. Some people use them more extensively. As the message mentions, you can actually make changes and commit them, which creates new commits that are not and have never been on any branch! (If you do that, git reflog can help you find them later... or you can... not do that.)

You can get back to a branch by checking it out, as usual.

After you do that, try checking out the commit at the tip of a branch by its hash.

One convenient way to get the hash, when a branch is checked out (i.e., you're not in a "detached head" state), is to run:

git log -1

Since that shows the log entry for just the current commit, which is the latest commit on (i.e., the tip of) the branch you're on, when you're on a branch.

@EliahKagan done... same thing happened

Right. Even when the commit you check out is one that is at the tip of some branch and thus is referred to by a branch name, you're still checking out the commit, and new commits on the branch don't change where you are.

But that's not in practice a reason to do it, typically, because you can just make a new branch, and then changes on the branch you made it from don't affect where you are when the new branch was checked out.

This is to say that one reason to branch is to avoid affecting the branch, often master, that you branch from. But another is to avoid being affected by the branch you branch from.

Anyway, as you've observed, a commit can be at the tip of multiple branches, so git checkout wouldn't know which branch to check out anyway, if it checked out branches when you gave it a commit hash.

So I'll often talk about branch names being ways to refer to commits, which they are, but the effect of using a branch name is not always the same as the effect of otherwise identifying the commit that branch name refers to, because git has a notion of being on a branch, and checking out a branch puts you on that branch. (Other actions, like creating the initial commit in a repository or cloning a repository, also put you on a branch.)

Please let me know if any of that doesn't make sense.

So something we've been talking about doing is to make the master branch (or, in any case, the tip of the master branch) not have the files TO-TEST/AlooKurma and TO-TEST/BeetrootChutney.

it makes sense. I think I am getting the idea of a branch vs a commit

@EliahKagan yes, I keep sidetracking. I'm infamous for this. I never get to the end of any anecdote...

brb

@Zanna :)

Well, it was very much my intention to cover this other stuff before that, at least to cover what it's like to make changes on an existing branch and to move between branches and see the changes in your working tree.

@EliahKagan Your major options for that are git revert, which makes a new commit that is the opposite of some existing commit (and with no arguments it's the opposite of the latest commit on the current branch) and git reset ... (where ... is the commit to reset your branch to, which effectively deletes the more recent history of the branch).

(back)

git revert is safer in the sense that it doesn't destroy or even obscure any information. However, it does have one significant disadvantage to git reset when it comes to undoing a commit that belongs only on a feature branch but got committed to master (or whatever branch the feature branch came off of) before the feature branch was created. I'll get to that. What I recommend you try first is to make a silly change in the New branch and then try reverting it.

ok

The change will still appear in the history of the repository.

Since git revert simply makes a new commit that does the opposite of what a previous commit did.

ok, so I added a line to the file I made earlier in New and committed the change

now I've thought better of it and I want to get rid of that line

Cool. So now run:

git revert

it gives me a usage message

wants an argument

Oh.

Sorry, that's my bad. I don't know why I remembered it wrong. I revert somewhat often.

So tell it what you want to revert.

Since you want to revert the latest commit, you can specify that as HEAD.

no worries!

@EliahKagan oh yeah, that's a good reminder of how I can use HEAD

When you're on a branch, HEAD is equivalent to specifying that branch rather than the commit at its tip... but for most purposes, basically everything except git checkout, specifying a branch has the same effect as specifying the commit at its tip.

Having reverted the commit, run:

git log

This will show the reverted commit as well as the newer commit that reverted it.

$ git log
commit 75a98a9514dd9dab26277ef0137ea47f01510550 (HEAD -> New)
Author: Zanna <redacted>
Date:   Tue Aug 6 13:40:41 2019 +0100

    Revert "Added an unnecessary line to a file, for science"

    This reverts commit 92285229e68922babdafce12165b1a1f6d6d5e2e.

commit 92285229e68922babdafce12165b1a1f6d6d5e2e
Author: Zanna <redacted>
Date:   Tue Aug 6 13:34:26 2019 +0100

    Added an unnecessary line to a file, for science
[...]

Because git revert doesn't rewrite history, you can use it on branches that are remotely tracked, even if the commit you're reverting has been pushed to the remote repository, without causing problems.

no danger of confusion

So now, I recommend you go ahead and make another change you don't want... but this time, use git reset to "actually" undo it.

in this case, git did some work for me because I didn't have to actually delete the line myself

Yes.

@EliahKagan I scare-quoted "actually" because, even after a reset, the change is still present in the repository at least as long as it is referenced in the reflog.

Unlike git revert, the argument you pass to git reset tells it what commit you want to reset to.

So to reset to the state before the latest commit, you'd reset to the commit before that.

oh, I ran git reset after making the change and committing it, and there was no output

Also unlike git revert ..., when you run git reset ... without options, your working tree may be caused no longer to be clean.

@Zanna Provided you reset to a commit other than the one you were already on, it should have done something, even if there was no output. What's the output of git log and git status now?

git log shows the last commit where I made the bad change

@EliahKagan That git reset ... may unstaged files in the working tree is really a feature, not a bug, because it keeps you even farther away from losing data. You can delete those files if you confirm you don't want them or that they are in another branch.

$ git status
On branch New
nothing to commit, working tree clean

@Zanna So it... didn't undo that commit?

seems not

What git reset command did you run, specifically?

git reset

Oh.

was the whole command

You should pass an argument indicating the commit you want to reset to.

ok :)

I had already run that before reading your messages about what argument it should have earlier

but since there was no output, I assumed some kind of success

so I asked about what happened instead of trying anything else

You assumed correctly, in that it succeeded at doing nothing. :)

haha great

I'll show you what git reset without arguments is actually for shortly. In hindsight I should have covered that first because it's the more common use.

Anyway, did running git reset with an argument reset to before the latest commit?

yes

and it showed

Remember you can use ^ or ~ notation with HEAD to specify that.

Cool.

Unstaged changes after reset:
M	TO-TEST/TomatoChutney

@EliahKagan thanks, I should have done that :)

So, you can check out branches and (less usefully) commits. That's one kind of use for git checkout. Doing so checks out all the files at the commit referenced by the specified branch (or at the commit you specify directly).

But you can also check out files.

ooh

You can check out individual files, or you can check out locations. Like you can check out . at the root of your repository to check out everything.

You can do both at once -- you can specify both a branch or commit to check the files out from and a path to check out.

But often you'll just want to check out an individual file or . to undo changes.

This is a destructive operation if the current files are different and not committed.