6. What is a commit?#

Warning

Due to events beyond my control the full details for this class were lost. Below contains all of the notes and explanation, but not every command that was run and the actual output at each step.

No notes yet because I made an error and did not save my terminal output from the codespace before I left the classroom.

To produce the notes, I will have to use the commit history and the prismia log to re-do the activity in a copy of my repo that I manipulate to undo things so that I can recreate.

6.1. Housekeeping#

6.1.1. In class time#

reminder: you are expected to follow along with what I model in my terminal and use prismia as a backup if you miss something or get an error.

6.1.2. Notifications#

reminder: I post announcements as releases

To get notified, watch the repo.

6.1.3. Penalty free zone is over.#

  • all past badges can be submitted at any time

  • all badges posted today going forward have deadlines per the syllabus

6.2. Why study what a commit is?#

A commit is the most important unit of git. Later we will talk about what git as a whole isin more detail, but understanding a commit is essential to understanding how to fix things using git.

today we will continue organizing the github inclass repo as our working example.

In CS we often have multiple, overlapping definitions for a concept depending on our goal.

In intro classes, we try really hard to only use one definition for each concept to let you focus.

Now we need to contend with multiple definitions.

These definitons could be based on

  • what it conceptually represents

  • its role in a larger system

  • what its parts are

  • how it is implemented

6.3. Using a GitHub Codespace#

Today we will also work in github codespaces.

  1. Navigate to your github inclass repo on Github.com

  2. Use the link in the README or the green code button to open a new codespace on main.

You are allowed to have two active code spaces at any point in time. If you get an error, you have some still open. Use the codespace page to see all of yours.

You can deacitvate any that are running that you do not want to use.

Important

Remember: codespace is a virutal machine on a cloud platform, not cloud access to github.com

  • you need to commit changes

  • codespace is linux

this is why i teach bash

as developers, we will all interact with linux/unix at times, so bash is the best shell to know if you only know one or do not want to switch between multiple

6.4. Multiple cursors are your friend#

docs

We used multiple cursors to remove the > from the beginning of each line in the README file that we we made last class.

6.5. Conceptually, a commit is a snapshot#

storing data as snapshots over time

6.6. A commit is the basic unit of what git manages#

All other git objects are defined relative to commits

  • branches are pointers to commits

  • tags are pointers to commits

6.7. parts of a commit#

We can use git log to view past commits

here we see some parts:

  • hash

  • (if merge)

  • author

  • time stamp

  • message

but we know commits are supposed to represent some content and we have no information about that in this view

we can view individual commits with

git cat-file

Now we see more detail:

  • hash (used to access)

  • tree

  • parent

  • author with timestamp

  • commiter with timestamp

  • message

6.8. Commit parents help us trace back#

kind of like a linked list

6.9. Commit trees are the hash of the content#

This separation is helpful.

Let’s make a commit that includes changes to two files

After the commit we can use

git reset HEAD^

to put the head pointer back and reset the working directory back to how it was at that point as well.

The git reset docs describe this in great detail.

6.10. Commit messages are essential#

A git commit message must exist and is always for people, but can also be for machines.

the conventional commits standard is a format of commits

if you use this, then you can use automated tools to generate a full change log when you release code

Tooling and examples of conventional commits

6.11. Prepare for Next Class#

  1. Read the 2023-09-26 notes when posted

  2. Make sure that the gh CLI tool works by using it to create an issue called test on your kwl repo with gh issue create

  3. Take a few minutes to think about a time you were debugging or pay attention the next time you debug something. Make note of how you think about the problem, how do you decide what to check? how do you decide what to try? what information do you look for?

6.12. Review today’s class#

  1. create an issue on your group repo for a tip or cheatsheet item you want to contribute. Make sure that your contribution does not overlap with one that amemb

  2. clone your group repo.

  3. work offline and add your contribution and then open a PR

  4. review a class mate’s PR.

  5. Export your git log for your KWL main branch to a file called gitlog.txt and commit that as exported to the branch for this issue. note that you will need to work between two branchse to make this happen. Append a blank line, ## Commands, and another blank line to the file, then the command history used for this exercise to the end of the file.

6.13. More Practice#

  1. Find a resource/reference that helps explain a topic related to the course that you want to review. Make sure that your contribution does not overlap with one that another member is going to post by viewing other issues before you post your issue. Create an issue for your planned item.

  2. Clone your group repo.

  3. Work offline to add your contribution and then open a PR. Your reference review should help a classmate decide if that reference material will help them understand better or not. It should summarize the material and it’s strengths/weaknesses.

  4. Complete a peer review of a class mate’s PR. Use inline comments for any minor corrections, provide a summary, and either approve or request changes.

  5. learn about options for how git can display commit history. Try out a few different options. Choose two, write them both to a file, gitlog-compare.md. Using a text editor, wrap each log with three backticks to make them “code blocks” and then add text to the file describing a use case where that format in particular would be helpful.

6.14. Experience Report Evidence#

write your git log to a file and include it with your experience report.

6.15. Questions After Today’s Class#

6.15.1. Can you use the terminal for any IDE that is not only VScode in Codespaces?#

Yes.

6.15.2. What is the difference between using git reset and git revert?#

git revert applies a new commit that is the opposite of the one that you want to “undo” reset actuall resets everything back to a particular point.

6.15.3. How can I learn more neat tricks like multicursor?! Very usefull and I do not know how I have never known about it.#

I think most developers learn things like this from talking to one another or reading blogs/watching youtube/ following on social media.

We will have a class on IDEs later, where one of the tasks is for you all to share tips.

6.15.4. Is there always a way to return to a state of a repo, no matter how far along or how much as been commited or changed?#

Yes

6.15.5. What does the commit message convention you showed us in class do? It needs a script to attach to it but what is the end goal of the scripts?#

It allows a script to process the commit messages in order to produce a change log.

Important

Learning more about this or using it throughout could be an explore/build badge

6.15.6. Is there a way to write a script to automate this process so that I don’t need to write as many commands?#

Yes we will write scripts in a few weeks.

6.15.7. Is it more efficient to look for the commit id and create a branch off it in the terminal rather than to do it manually in github?#

Often yes.

6.15.8. Do you know of some situations where restore saved the worst possible mistakes in a repo?#

Yes, reverting and restoring helps fix bugs all the time. It is also how people can remove data that should have never been commited, before pushing.