@Zanna Do you have some binary files in the repo?

It's fine if you do. git won't give you good diffs for them, but it tracks them just fine. I'm asking because I think that may explain the difference in the number of insertions git reported vs. the number of lines wc reported.

@EliahKagan yes, there are some images there, which are photos of recipes written on paper. This is a temporary thing - if they are in that state I need to test them and then write a new version as text. So maybe those should be special-cased. Actually the main reason I decided to convert my entire recipe collection to text was so I could grep it easily. That's very useful to me. So I really want to process the binary files as a priority

Cool. I believe that explains it.

ah yes

I only remembered that last night

You can have git tell you what files it consider to be binary files like this:

as I was falling asleep I thought of those files

:)

cool

If you have big binary files or a large number of moderately sized ones, that may be slow, in which case you could use file to guess which files are binary, for example by running this in the root of the repository:

IFS= read -r filter <<'EOF'
file --mime-type -- "$@" | grep -Pv ':\s+(?:inode/(?:directory|x-empty)|text/\S+)$'
EOF
find . -path ./.git -prune -o -exec sh -c "$filter" sh {} +

filter is a bad variable name because it's not just filtering, it's also adding the file type to the output. Oh well. :)

the command in that answer didn't take any noticeable time and returned 4 files

that seems right

Cool

You can run wc -l on those files to see how many "lines" they contributed to the output of wc -l on everything.

(Unless they are dotfiles -- your wc -l command from before was not passed the names of dotfiles.)

(I have some more images to deal with but they are in another place)

I think you may be able to OCR your text-containing images.

  10822 SweetStuff/ChristmasCake.jpg
   4452 TO-TEST/BerryCheesecake.jpg
    537 TO-TEST/LeonCaribbeanPlantain.jpg
    715 TO-TEST/ottolenghicoronationchickpeas.jpg
  16526 total

I wrote text messily on a whiteboard. Someone with a better phone camera than I have took a picture of it and emailed it to me. When I search Gmail through my web-based interface, it finds correct search results in my handwritten text.

@EliahKagan For a couple, that would help, but for most of the images I have using OCR would not be the most efficient way for me to process them, because I will change them a lot when I make them

@EliahKagan wow cool!

Makes sense.

@Zanna Yes. People should be aware of this, because it can also be used for evil. (It is good for people to know what kind of analysis on their data is efficiently practical, as well as what kind is currently being done. People know their text is indexed but may not know images are indexed in a comparable way now.) But it is very handy. I wish Gmail actually offered me an OCR'd document. That would make it even more useful.

indeed

@Zanna That seems exactly right. With the numbers from yesterday:

>>> 22870 - 6344
16526

haha did you also start a python3 shell to do arithmetic? That's what I did

Anyway, Git is still totally fine for those images. It just doesn't report their data as insertions.

@Zanna Yes I did.

:)

I mean, Python 2 is going to be unsupported soon!

hahaha

I should say that the reference implementation of Python 2 is going to be unsupported soon. Some other implementations, like pypy, will continue to support it.

Also github.com/naftaliharris/tauthon. :)

Have you made any more commits to your repository, beyond that initial commit?

@EliahKagan haha nice

@EliahKagan no I haven't done anything, but it was on my mind

sorry I need to go afk for a bit

k

few chores I need to do now

will be back later but of course no worries if you are not around then :)

@EliahKagan To keep "empty" directories, I think Acumenus is right in saying that .keep is a better filename than .gitkeep:

(See also this comment.)

@Zanna Welcome back! :)

If this is the "later," it works for me. But definitely no problem if it isn't.

@EliahKagan ^_^ thanks

yes I am somewhat here now

That would be a fair description of my status. :)

That and "using too many smiley faces."

Did you make any subsequent commits? If not, do you wish to do so now?

I am also sharing some recipes and tips with someone in the vegetarianism chat room, but any confusion would probably be quite fun

@EliahKagan I like those

@Zanna Why would that cause confusion?

@EliahKagan I haven't done anything. But today I invented something good and I want to write it down. So I'll be creating a new file. Also, I think some directories are in danger of becoming empty, so I'll need to create some files to prevent them from disappearing, right?

Assuming you do actually want to keep the directories.

@EliahKagan I mean I might send messages intended for one room to the other

yes I think I want to keep them all for now

To be clear, git doesn't remove empty directories in your filesystem that it sees are empty. Instead, when it removes the last file from a directory, it deletes the directory.

@Zanna You could move the messages, though, right?

@Zanna Yeah, so you can put .keep files in them, if there's nothing else to put there.

Or maybe they should have README files explaining what they're for?

Btw, since those files are files you're using for some actual purpose, you might also want to make a new repository just for trying stuff out with git.

or

You could make a separate branch in your existing repo for playing around with stuff.

I think it would be easier to understand branching once you've made a commit with a parent, though.

A commit can have however many parents. Most commits have one. An initial commit has zero. A commit that results from a merge can have more than one.

or

You could clone some totally unrelated remote repo and play around with that.

or

No, just kidding, that's all I've thought of.

Do any of these options appeal to you?

@Zanna I thought to check my belief that you were an owner of that room (since to move messages one must be an owner of the room they start in). You are... but also I noticed that none of the current mods on the site are owners of the room. That seems... odd!

Or does that not matter because they have mod powers anyway?

@EliahKagan I became the owner of that room automatically since I was the most active person there in the period immediately after its creation, I think

should I have made the mods owners of the room?

I don't know. I guess you should ask them.

I assumed they would be able to do that themselves

@EliahKagan yes... except that none of them ever comes to the room

@Zanna I think they can. They might prefer to defer to you about it since you're the original owner.

well, one of them did come there briefly a month or so ago after about a year of absence

@Zanna On the other hand, maybe they don't want to appear as owners because they never come in the room and don't want to be bothered with stuff about it.

@EliahKagan yeah, it would be more polite of me to make them owners...

But I am sure you can find a way to ask them even if they're never there.

OTOH if they're never there I think making the offer is quite optional.

@EliahKagan that's what I thought... since they are not coming there I didn't feel that they wanted to be saddled with it

@Zanna Well, unless they don't want to be owners. I mean, even then it might be more polite, but it might not be more good. :)

:) yes, these things are not the same

Anyway, any owner, mod or not, can remove themselves as an owner. So I don't think it's very bad to make them owners. But personally I'd ask them first.

Should we have another room to move side conversations from the island to that are about moderation? :)

one of the mods reviews flags. She doesn't come to the room at all. The one who came to the room does not seem to come to the site ever. And the other one does not seem to come at all to either the room or the site

I am tempted to move this to the downboat even though it's not about AU, because I would be of interest to most or all users who ever visit or read the transcript of the downboat. But I won't do so, because it's not necessary. If you want to, though, you have my support it (and I will do it if you ask me to).

@Zanna So the site has one active moderator, in other words?

one relatively active moderator, yes

but it is a very quiet site

Okay.

So do you want to commit again in your existing repo? Make a new sandbox repo? Make a branch in your existing repo? Clone a repo? Something else?

I think this conversation can stay here even though it's about moderation haha

Indeed. It's not about moderation on AU and we're not flexing our terrible powers.

haha indeed

@EliahKagan I think I want to try to do things with the existing repo, because if I'm doing things that I have some reason for doing, I'm more likely to remember how to do them

Okay.

If you do a commit and want to bring things back the way they were before, you can revert the commit. This makes another commit that does the opposite of that commit.

You can also reset the commit, which actually removes it from the repository's history. Usually it is better to revert, and if the bad commit was pushed to a remote, then it is almost always better to revert than reset.

because it might leave some confusion about what happened?

You can also amend a commit. It is sometimes reasonable to amend the most recent commit, mainly if you meant to commit something different (rather than if you did the wrong thing but meant to commit it, since in that case the history could still be helpful).

I make a lot of mistakes

@Zanna Reverting leaves the history intact. You don't have to think about whether or not you pushed the commit. Also, there is less risk of accidental data loss when you revert. Resetting a commit and amending a commit can be undone in a local repository, but the information necessary to undo them is not send to a remote when you push (which is quite intentional). Also, they may eventually become impossible undo in the current repository.

@Zanna Git is great for that! :)

:)

You won't see much now if you only have an initial commit, by try running:

git log

I see my initial commit haha

so, better do something else

That's the history, up to some commit. With no arguments (after log), it's up to where you you are now.

That is, up to the commit that is currently checked out.

I'll write a new file

@Zanna I encourage this, yes. :)

Excellent.

If you know you want to keep directories even when empty, you can put files like .keep in them.

Though I suspect you're making some more interesting new file.

Or perhaps less interesting.

Or equally interesting.

I will stop talking now for at least five seconds.

I made a new file :)

@EliahKagan I'll do that too

Cool. This is good, IMO, because your new file is probably conceptually unrelated to those .keep files. Therefore you may wish to commit them separately. This is easily achieved by only staging (i.e., adding) what you want to commit, and it's the reason staging and committing are separate in Git.

I usually use a rename or a text file which I remove after i have other files in that directory. And for the most stuff when I write kind of installer script into my python code to create the directories which are non present and needed.

Hi @Videonauth! :)

hey hey :)

for d in */; do touch "$d".keep; done

and done

I had this kind of problem with the discord bot im working on since a while

Oh, cool. What does your bot do?

I have not tried writing a Discord bot, even though I use Discord quite a bit.

It provides a database search for ProtonDB with in their official discord server

protondb.com

Nice! I should learn more about Proton. DXVK is really cool.

the bot simply lets people search within this pages DB for games and provides a bit more info

proton/DXVK came a long way within a few months

almost all my windows games i ditched for using linux now work out of the box

strengthens my belief that my change to linux was good and right

@Zanna So, assuming you want separate commits for the new file you created first and the .keep files, you can do it in either order. I suggest committing the first file (the non-.keep file) first. It's easy to add a single file by giving the path to that file rather than . as the argument to git add.

git add is recursive for directory arguments, so you can add all the changes in your whole working tree (other than stuff that's ignored in a .gitignore file and special files of kinds that Git won't sync) by running

git add .

in the root, as I think you did when staging for your initial commit.

To stage only some stuff, don't do that. :)

(Or do it but then unstage what you don't want staged.)

Usually you have an IDE which allows you pretty easily to commit and push single files without shelfing the other edits

yes that was the command I used the first time. OK I'll commit the exciting new file haha

but that can be done via command line too its just messy and i never got the knack of it properly

@Zanna git-scm.com/docs/git-commit

Now I've done that. But while I was writing my commit message, I was told that I had another change which was not staged

@Videonauth Yeah. I should've mentioned that. Personally, I tend only to use IDE integration for staging and committing changes to all files at once. But that's personal. But many people prefer to do fine-grained stages and commits from their editor/IDE.

@Zanna Well you do. The new .keep files, at least.

So what does git status show now?

earlier I deleted a file I noticed which was a file Vim created because it was interrupted while I was editing a file in the same directory

that was the change that was pointed out

Oh, you mean a .*.swp file?

@EliahKagan staging single files allows you to push out a hotfix to a branch which might be in production use or beta testing already and since on GitHub you can mention your issue with #<number> in the commit meessage and get that in the logs there its nice to have the more fine grained control.

On branch master
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:    ChutneySauceSpreadDip/.CarrotSunflowerSpread.swp

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

	BreadPancakes/.keep
	ChutneySauceSpreadDip/.keep
	CurryStewMain/.keep
	DryProtein/.keep
	NeedsWork/.keep
	PastaNoodles/.keep
	PieCasserole/.keep
	RiceGrains/.keep
	SnackyCrunchy/.keep

@EliahKagan yes

@Videonauth Yeah, I selectively stage and commit quite a bit. It's handy. I just don't usually use the IDE's interface to do it.

@Zanna You can put that glob pattern in a .gitignore file.

@EliahKagan example: github.com/Videonauth/ProtonDB-Bot/commit/…

@Zanna Oh, the .swp file was actually committed?

this is a file that tells git which files I want it to ignore?

@EliahKagan yes, because I only noticed it after I had made the repository

@Zanna That's fine. I'd go ahead and commit its removal though. If it had been added in the most recent commit, you could amend that commit to remove it, but it's not the most recent commit anymore, so I don't recommend doing git commit --amend for that. I think it would be reasonable to do that together with adding the .keep files... but also reasonable to do them separately, which is an opportunity for more practice, so I encourage that.

Beginning of this year i have had the bot completely rewritten to make it modular, that was a PITA to be honest, but as well an excellent opportunity to learn a lot about that for python

Thanks for the repo link for the bot btw.

yeah I mean the bot is pretty primitive and still uses requests instead of aiohttp for getting the website data , so if you would want to scale it you would pretty soon run into the limits of the request library and async handling requests will become a neccesity

@Zanna You can, somewhat counterintuitively, use git add to stage the deletion of a file you have deleted.

but for checking out how its done it is great as it is not very big script yet

@EliahKagan so, do I give the path of the deleted file?

Yeah.

Relative paths are relative to your location when you run the command, so if you're in the directory that had the file, you can just give git add the filename.

you can do as well the whole deletion or movements with git directly git rm <filename> will do the removal of the file so you see it already as a change with git status

or git mv <filename> <destination>

Yeah, that's true.

ok, I did two separate commits for the deletion and the addition of .keep files

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

Cool. Now the output of git log should be more interesting. :)

yes!

Regarding git rm, that will also stage the removal. (git status shows both staged and unstaged changes.)

@Zanna The output of git reflog should be even more interesting.

$ git reflog
59b3912 (HEAD -> master) HEAD@{0}: commit: Added .keep files to preserve empty dirs
8aa313f HEAD@{1}: commit: Removed .swp file
4b22aef HEAD@{2}: commit: Added new recipe
fb5dba5 HEAD@{3}: commit (initial): Getting Started

indeed

I wonder what all that means!

I assume you're asking just about git reflog's output?

yes

That's a history of what has happened locally.

Right now it doesn't really give information that's not in the log.

each commit has a small hexadecimal identifier, to which you even can re base your head in the worst case and this way roll back messy edits just one function of the log.

Yeah, the hex values shown in the reflog are abbreviations of the full hashes that git log shows by default.

lets say you want that .swp file back you can pull it from this commit into your current branch

and and and

You can perform operations based on any unique prefix of the full hash.

Including the whole thing if you want.

cool

here an excerpt of the log my bot has ammassed meanwhile

commit 87ae87f813772cf0913887aabfcbd918808a7f5b
Author: Videonauth <videonauth@googlemail.com>
Date:   Thu May 9 17:22:48 2019 +0200

    fixed: linter error
    issue: #5

commit c82f87ced5bb29298aea4c34fda6b937deeab140
Author: Videonauth <videonauth@googlemail.com>
Date:   Thu May 9 17:16:15 2019 +0200

    removed: unused import statement to fix linter error

commit 70e2d90c246eb05e489233ada745fd5d15ecf4b4
Author: Videonauth <videonauth@googlemail.com>
Date:   Thu May 9 17:09:50 2019 +0200

    implemented:moderation

we can use this to avoid messing up /etc perhaps

You mean by using a git repo for /etc?

yes

Yes. You'll need to be root for that, of course.

only if you use a private repo /etc has to many stuff in it which could be used by other people to gain access to your machine

Yeah, I would definitely not put a repo that has your /etc/shadow (and various other files, like /etc/shadow-) on a public remote.

hahaha

I suppose you could use GitHub for it but make it a private repo. I suppose. :)

So, this is really most interesting when you have files whose contents have changed (rather than being created, deleted, or moved/renamed) but... I suggest trying git diff.

you have a few private repos free on github, only limit is you can have only three collaborators on such a private repo

Is the number of private GitHub repos actually limited, or just the number of collaborators?

no I was just thinking of being able to rollback to before that "experimental" change you made to some crucial configuration file. But if the system won't boot, you're unable to use sudo , etc, it's probably not all that useful...

@EliahKagan it's empty

@EliahKagan afaik only the number of collaborators

but I've just found a file I'd like to change the title of

@Zanna I mean, you can boot into a live environment and manage the repo. Local repos aren't tied to any particular OS installation.

so I'll do that

@Videonauth Cool.

@Zanna So, this time, after you make a change but before staging it, try running

git diff

I use a private repo to backup my raspian apache settings and the like on it for my raspberry

(If nothing is staged, your index is the same as the commit you're currently on.)

@EliahKagan wow, very interesting

since I renamed the file, the whole file shows as deleted

it comes up in red with every line starting with minus

(do you ever find yourself trying to tab-complete the destination name of the file you're renaming? Like, why isn't Bash reading my mind?!)

Yeah, git isn't looking at files that have never been committed and aren't staged. This is sort of a confusing first way to try out git diff.

@Zanna Yes.

did you rename it via git or only in bash and then commit the deletion and the new creation?

@EliahKagan it makes sense. I haven't added the new file I created by renaming

to the repo

Good point -- it's often nicer to use git mv.

I didn't know there was such a command :)

git mv produces zero difference when the file itself was unchanged

ah

well the filename is in the directory, not in the file

@Videonauth Though that should also be the case if you run mv and then stage the new file, right? Doesn't git figure that out, because the file hash is the same?

@EliahKagan you can test it is you use mv only i had occasion where it showed me the file deleted and then a new one created

Interesting.

even tho it was the same file

just different file name

It's always worked for me... but I guess not always and I should use git mv. Ironically, moving and renaming files is something I often do do in an editor or IDE's interface.

When it notices the similarity I get:

ek@Gnar:~/source/repos/tmp (master *+%)$ git diff HEAD
diff --git a/textfile b/textfile2
similarity index 100%
rename from textfile
rename to textfile2

here i have used git mv --> github.com/Videonauth/ProtonDB-Bot/commit/…

that's more like what I would have expected than what I got

What did you get?

still searching for the case where it recreated a new file

$ git diff
diff --git a/RiceGrains/KalePomegranatePulao b/RiceGrains/KalePomegranatePulao
deleted file mode 100644
index 259da41..0000000
--- a/RiceGrains/KalePomegranatePulao
+++ /dev/null
@@ -1,30 +0,0 @@
[full text of file in red with minus signs]

Oh.

Did you stage the renamed file?

no

If the "removal" is staged but the "creation" isn't then it will look like that.

@EliahKagan ^

Videonauth is extremely right that git mv is less confusing.

@Zanna Yes.

it's ok, I understand why it looks like that

Cool.

Have you yet staged it with the new name?

If not, you may be interested to see the output of

git diff HEAD

or at least it makes some sense to me

@EliahKagan hmm, it is the same

Oh, okay.

@EliahKaganin those two commits i had this happen see one commit it created a new file and a commit later it deleted the old file from the repo github.com/Videonauth/ProtonDB-Bot/commit/… and github.com/Videonauth/ProtonDB-Bot/commit/…

@Zanna Oh, sorry. That's what you should see. I tied my mind up into knots.

wonder if that was a hickup by the IDE but since then I use git mv in terminal

@EliahKagan no worries :)

I meant that you may find it interesting to see the output of git diff and git diff HEAD both before and after staging the file.

I'll stage it

aha

@Videonauth Hmm, yeah I don't know why that is.

so git diff outputs the same as before, but git diff HEAD shows what you showed earlier

me neither just saw ok when using git mv i do not have this

Well at least it worked.

@Zanna Not really, no.

I mean it does.

In this case.

Sorry about the confusion.

I was merely reporting what I saw

not a conclusion I've made

Yeah, my "sorry for the confusion" was about my wrong "Not really, no," thing.

Sorry also for the meta-confusion :)

git diff shows you the difference between

well, it's different, but in trivial kinds of ways haha

(a) what's staged, and

(b) the files in the working tree that git knows correspond to something that is tracked in the repository.

In contrast, git diff <commit>, where <commit> refers to some commit, shows the difference between:

(a) that commit, and

(b) [as before] the files in the working tree that git knows correspond to something that is tracked in the repository.

So often you'll want to use

git diff

before staging, but

git diff HEAD

after staging.

This would perhaps be less confusing if I had first said what HEAD is.

HEAD is an a symbolic name for where you currently are.

when you say where

what does that mean?

I mean HEAD refers to the commit or branch that is currently checked out.

So, when you run git log (with no argument) it will say which commit the HEAD is at.

hmmm

Does it not show that?

yes it does

or at least I believe you that it does

(It's possible for it not to... but I've only seen that happen in repos with no commits and in bare repos.)

or that what it shows is in fact what you are saying it shows :)

Can you show what it shows? :)

yes, but I don't think I'm hmmming because I feel it doesn't show what you said... rather I am feeling that this where is a pleasantly strange unfamiliar place that I need to get used to

Oh.

Nice.

Well, the git checkout command is very related to that.

git commit -m 'One does not simply merge into master!'

:D

:)

$ git log
commit 59b39125d717a979d92eb9e6a969d5f51a9f4b1b (HEAD -> master)
Author: Zanna <redacted>
Date:   Fri Aug 2 13:06:37 2019 +0100

    Added .keep files to preserve empty dirs

commit 8aa313fe7dc84f4fbcd2e50735ee93b504cceb6f
Author: Zanna <redacted>
Date:   Fri Aug 2 13:05:55 2019 +0100

    Removed .swp file

commit 4b22aefebc31064392f3b4c0ff9e8d7a547196c2
Author: Zanna <redacted>
Date:   Fri Aug 2 12:54:11 2019 +0100

    Added new recipe

    Plums with Almond Cream

commit fb5dba55ac8f5e28aa104723107f880432fe2ea7

You can check out any commit. Even if it has no symbolic name, you can check it out by its hash. But I suggest trying out git checkout to move between branches first.

But ok since as far I understood Zanna is using git for her cooking recipes its not really necessary to branch at all

haha it's an educational exercise

I think it still makes sense to use a feature branch for changes to the recipes that might not be kept (though even without that, the old versions can be restored, of course). But yes, managing the recipes is not today's only goal.

Also, if one uses a remote, then separate branches exist, even if it's only master and origin/master.

im still always mix up git checkout <branch identifier> and git branch <identifier> :D

when i understood this right git checkout creates the branch on the remote and checks it out if it not exists and branch creates it locally ?

Neither creates an upstream (remote) branch. You can use git checkout to check out a local or remote branch. git checkout doesn't create a branch unless you pass the -b option in which case it creates a (local) branch and checks out that new branch. git branch creates a local branch without checking it out. Typically, a new remote branch would be created by pushing a local branch that isn't already tracked upstream.

ah ok

I should say that in the (common) use of git checkout to check out a remote branch, the branch it actually puts you on is the corresponding local branch, and if there isn't one, it creates one.

So it's not strictly true that checkout without -b doesn't create branches.

makes sense

@Zanna So right now you have one branch, master.

This is the branch that is created (by default, anyway) when you make your first commit in a new repository.

yes :)

I had mentioned before that each commit can have however many parents, and that most commits have one parent, but an initial commit has zero and a commit that results from a merge can (and often does) have more than one.

A branch refers to the tip of a series of commits. When you're on a branch and you commit, this causes the branch to refer to the new commit.

It's conceptually a "branch" because while it refers to one commit, that commit refers to its parent, which refers to its parent, and so forth.

Branches in git are very cheap because they don't duplicate commits that would be the same in different branches. In fact it is arguably a mere colloquialism to talk about commits being in a branch. (Arguably.)

So you can see all of a repository's local branches by running:

git branch

with no argument.

You can see both local and remote branches by running

git branch -a

with no argument (besides the -a option, which I think stands for "all").

$ git branch
* master

The * means that's the currently checked out branch.

ah :)

It's possible for no branch to be currently checked out, but if one is -- which is most often the case during the course of normal gitusage -- then it gets a * in the output of git branch.

You don't have any remote branches yet -- nor even any remote on which to have branches! -- so you don't see anything for that right now.

yes

When you run git branch with a non-option argument, that argument names a new branch that you wish to be created.

ooh

When you pass just one branch name, the branch is created from wherever you currently are.

I pretty much never pass two non-option arguments to git branch but you can do that to branch from anywhere.

So, I suggest making a branch, checking it out, and making at least one commit on the branch.

You can make a branch and check it out with one commit (git checkout -b does this) but I think it's useful to be familiar with making branches with git branch.

I will do that, but my plan for tomorrow has just changed dramatically and I unexpectedly need to go out and buy things

Ah.

sorry :|

Definitely not a problem -- Git will probably still be used when you get back!

hahaha XD

If I have time later, I will try to resume

I suspect Git will remain relevant even days from now. :)

I know why I suddenly have many things to do... it's because my dad has sent me some work. Without fail this causes all sort of important and useful things to present themselves to be given my time

Unrelated things?

(Sorry, perhaps I misunderstood what you meant.)

I'll hold off on pinging you about more Git stuff until you indicate you want to continue. Perhaps later (or another day) you can try using information from git reflog to recover "lost" commits, such as a deleted branch. I meant to mention one other git command that I should have shown before anything else yesterday, git help. By itself it lists commands and brief summaries. It also supports a command argument, e.g., you can run git help checkout or git help help, to display manpages.

The help is also online at git-scm.com/docs.