What is a commit?

6. What is a commit?#

6.1. Admin#

Penalty free zone ends with today’s badges

  • all past badges can be submitted at any time

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

  • There is a bonus for getting 6 badges completed (do not have to be approved) by 2/15.

6.2. Defining terms#

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

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

In intro classes, we try really hard to only use one definition for each term 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

for a commit, today, we are going to go through all of these, with lighter treatment on the implementation for today, and more detail later.

6.3. Conceptually, a commit is a snapshot#

storing data as snapshots over time

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

All other git things are defined relative to commits

  • branches are pointers to commits

  • tags are pointers to commits

  • trees are how file path/organization information is stored for a commit

  • blobs are how files contents are stored when a commit is made

6.5. Parts of a commit#

We will learn about the structure of a commit by inspecting it.

First we will go back to our gh-inclass repo

cd Documents/inclass/systems/gh-inclass-sp24-brownsarahm/

We can use git log to view past commits

git log

 1commit e3b192aa0cd490226e8adcd81d3d0b95adb5676b (HEAD -> organization)
 2Author: Sarah M Brown <brownsarahm@uri.edu>
 3Date:   Tue Feb 6 13:41:53 2024 -0500
 4
 5    oranizizng
 6
 7commit 260c9c309922970f80bfa2c93cc23bcfbb962740
 8Author: Sarah M Brown <brownsarahm@uri.edu>
 9Date:   Tue Feb 6 13:06:20 2024 -0500
10
11    describe the files
12
13commit 29ffc88519103085ed3a2ab01cffb3c99d70fc6a
14Author: Sarah M Brown <brownsarahm@uri.edu>
15Date:   Tue Feb 6 12:59:20 2024 -0500
16
17    add to readme
18
19commit 9f399466ad6a1ad572e104209f4469eb8cd48516 (origin/main, origin/HEAD, main)
20Merge: 1e2a45f fca59e8
21Author: Sarah Brown <brownsarahm@uri.edu>
22Date:   Tue Feb 6 12:43:18 2024 -0500
23
24    Merge pull request #5 from compsys-progtools/organizing_ac
25    
26    2/6 in class activity
27
28commit fca59e8cca05bb0861f9348a40fe8300b3d55637 (origin/organizing_ac)
29Author: Sarah M Brown <brownsarahm@uri.edu>
30Date:   Tue Feb 6 11:21:21 2024 -0500
31
32    add files for organizing
33
34commit 1e2a45fbca5ce7bf775827f5f4dbe23b6561cff4 (my_branch_cehckoutb, my_branch)

here we see some parts:

  • hash (the long alphanumeric string)

  • (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

the hash is the unique identifier of each commit

we can view individual commits with git cat-file and at least 4 characters of the hash or enough to be unique. We will try 4 characters and I will use the last visible commit above (1e2a45fbca5ce7bf775827f5f4dbe23b6561cff4)

git cat-file has different modes:

  • -p for pretty print

  • -t to return the type

git cat-file -p 1e2a 

tree d5c7c4543f48ca7fb5cf75881fd0dbe21d75f51c
parent faef6af98e6bd0951ebcefb809ff4e353a0c7fbc
parent 81c6f187f146caaaf43d97bc1bb8ed237142f4c3
author Sarah Brown <brownsarahm@uri.edu> 1706809877 -0500
committer GitHub <noreply@github.com> 1706809877 -0500
gpgsig -----BEGIN PGP SIGNATURE-----
 
 wsFcBAABCAAQBQJlu9oVCRC1aQ7uu5UhlAAAxpQQAFxq5TBSKvb2Qoyilvayo80x
 9mY1stuFWwm2ymZhIGLJbJMbJ6ZAnlpfyAZHfQ/QQ7MnPdlt/GIAKKtIo+NLUkZj
 9aDQMk1vjkP1IEx1LjAjxoVHTvEKsDPWxKNlPLjyg9KqYH83LVtQYaMT788YNHaL
 Bcg7vgAbSmpDtn84HPmXGvgq7/V7kJyl/zADxDJaA+3ETHGehm7Fkuo6UdsbaPZH
 5is6eYsNwTrC/19vdnZcr9Gcfr6mNzttyiQDkiUZ1A77Eucrk4Di/W++JLjq/ufk
 Kl6M1T/ItpWQx3DmgoKTYcX5TsHQaS8ONCaGDDHimL6P+f4os7dHboYU6aDFipgt
 WyrLKnCRCIrVzEwHJvWCGHiUW50Ho3yOpwi/1N24U8mXBckKGP59Tgtv+Ef6Zik1
 Aj+qFzRM1d0/A/c3MYBbmBtdcdlS/dVwLu9uqGq+DjSrPoi8T292YVC6YduQAe1i
 Effj9V6sGtyZv83ZkCCig1SKfbt4zoW1P1zK14XVNdcIRrDwwyKXfqKUUl4k9gZV
 1yjMHVEaljA4Ey3qrn4rwh5teaZpAsPrj/5FF6roUeNUoD7iXXq3MHDz619otALB
 o9Xe4x/Zn167j9M0R78Gid6qOQxQx+LgtOjqidwt1HjlOgLUEgSDloFpxhgH56Ec
 TVSXjxLMrPrRlf+4ZaAZ
 =0h+s
 -----END PGP SIGNATURE-----
 

Merge pull request #4 from compsys-progtools/2-create-an-about-file

create about file close s #2(base) brownsarahm@gh-inclass-sp24-brown7
040000 tree 95b60ce8cdec1bc4e1df1416e0c0e6ecbd3e7a8c	.github
100644 blob 2582d225ab3de985146828e170a4320b16df5206	README.md
100644 blob 9ea743825de328435ce38670898e4109619a4d15	about.md

Now we see more detail:

  • hash (used to access)

  • tree

  • parent

  • author with timestamp

  • commiter with timestamp

  • message

6.5.1. What is the PGP signature?#

Signed commits are extra authentication that you are who you say you are.

The commits that are labeled with the verified tag on GitHub.com

If we pick a commit from the history on GitHub that does not have verified on it, then we can see it does not have the PGP signature

git cat-file -p fca59e8cca05bb0861f9348a40fe8300b3d55637

tree aa02c633322970a4095e564aeb8fd96a3d4f31ab
parent 1e2a45fbca5ce7bf775827f5f4dbe23b6561cff4
author Sarah M Brown <brownsarahm@uri.edu> 1707236481 -0500
committer Sarah M Brown <brownsarahm@uri.edu> 1707236481 -0500

add files for organizing

6.6. How are commits implemented?#

commits are stored in the .git directory as files. git itself is a file system, or a way of storing information.

Everything the git program uses is stored in the .git directory, you can think of that like all of the variables the program would need if it ran all the time.

ls .git/

COMMIT_EDITMSG	REBASE_HEAD	index		packed-refs
FETCH_HEAD	config		info		refs
HEAD		description	logs
ORIG_HEAD	hooks		objects

the ones in all caps are files and the others are folders.

Most of the content is in th objects folder, git objects are the items that get stores.

ls .git/objects/

00	26	3c	74	86	9e	d3	f5
05	29	42	76	8c	9f	d5	f9
07	2b	5b	79	8e	aa	d8	fc
0c	2d	63	7a	93	ab	e0	info
1e	39	67	7e	9b	b0	e3	pack
1f	3a	6b	81	9d	c8	ed

We see a lot more folders here than we had commits. This is because there are three types of objects.

classDiagram class tree{ List: - hash: blob - string: type - string:file name } class commit{ hash: parent hash: tree string: message string: author string: time } class blob{ binary: contents } class object{ hash: name } object <|-- blob object <|-- tree object <|-- commit

Each of those folders is the first 2 digits of at least one hash, or unique identifier for an object. We can list what is in one of those folders

ls .git/objects/26

0c9c309922970f80bfa2c93cc23bcfbb962740

Mine has just one, most will in a small repo like this, but it could be mroe than one.

We can look at the plain file using cat

cat .git/objects/26/0c9c309922970f80bfa2c93cc23bcfbb962740 

x??Aj?0{?+?	+)?JJ?=??`??ņ?.?L??:O?i```d??C??ћ*`?*?h4L?"?kP???b%?LQJ??&Wv??qm?ōGx£??nÁ?p?}o?Y??	???%PF8aBt?????UݤM?Bl????%?Ko

The content of the file is stored in binary.

To be able to read it we have to use the plumbing command.

git cat-file -p 260c

parent 29ffc88519103085ed3a2ab01cffb3c99d70fc6a
author Sarah M Brown <brownsarahm@uri.edu> 1707242780 -0500
committer Sarah M Brown <brownsarahm@uri.edu> 1707242780 -0500

describe the files

then we can see the object, mine is a commit, so I see the info like before.

Some of us picked an object that wa a tree or a blob instead.

We can also check the type

git cat-file -t 260c 

commit

6.7. 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.8. Using a codespace#

Codespaces are a virutal machine that you can use VSCode on in browser. You only have VSCode access to this system, but VSCode with the terminal is a lot of power.

If VSCode is new to you, use their documentation of the VSCode interface to get oriented to the different parts of the screen.

Before we open a code space, we will first push our content.

git push

fatal: The current branch organization has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin organization

To have this happen automatically for branches without a tracking
upstream, see 'push.autoSetupRemote' in 'git help config'.

We follow what it says to do next.

git push --set-upstream origin organization

Enumerating objects: 14, done.
Counting objects: 100% (14/14), done.
Delta compression using up to 8 threads
Compressing objects: 100% (11/11), done.
Writing objects: 100% (12/12), 1.75 KiB | 1.75 MiB/s, done.
Total 12 (delta 3), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (3/3), completed with 1 local object.
remote: 
remote: Create a pull request for 'organization' on GitHub by visiting:
remote:      https://github.com/compsys-progtools/gh-inclass-sp24-brownsarahm/pull/new/organization
remote: 
To https://github.com/compsys-progtools/gh-inclass-sp24-brownsarahm.git
 * [new branch]      organization -> organization
branch 'organization' set up to track 'origin/organization'.

Now we will go to our browser.

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

  2. Use the green code button to open a new codespace on main.

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

  • 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

Here we can use the gh CLI, this allows us to use a terminal to do github operations instead of only git commands.

When we open a new code space, we get a fresh clone of the repo on the virtual machine.

One consequence of this is that if we list the branches, we only have one:

git branch

We have to list the remote branches, with the -r option

git branch -r

  origin/2-create-an-about-file
  origin/HEAD -> origin/main
  origin/fun_fact
  origin/main
  origin/organization
  origin/organizing_ac

Then we can check out one of the listed branches and make a local copy of the branch with gitcheckout

git checkout organization

Once we are on a branch, we can open a PR

gh pr create

It then prompts you how to make the PR

And we can merge from there too

gh pr merge

6.9. Prepare for this class#

  1. Bring git questions or scenarios you want to be able to solve to class on Thursday (in your mind or comment here if that helps you remember)

  2. Practice using the new bash commands we have learned to read and understand the workflow files in your KWL repo. Look for bash commands that we have seen before. Try to modify files on a prepare branch so that your name is already filled in when your experience badge (inclass) action runs.

6.10. Badges#

  1. 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.

  2. In commit-def.md compare two of the four ways we described a commit today in class. How do the two descriptions differ? How does defining it in different ways help add up to improve your understanding?

  1. Explore the tools for conventional commits and then pick one to try out. Use one of the tools that helps making conventional commits (eg in VSCode or a CLI for it)for a series of commits adding “features” and “bug fixes” telling the story of a code project in a file called commit-story.md. For each edit, add short phrases like ‘new feature 1’, or ‘next bug fix’ to the single file each time, but use conventional commits for each commit. In total make at least 5 different types of changes (types per conventional commits standard) including 2 breaking changes and at least 10 total commits to the file.

  2. 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. do this after the above so that your git log examples include your conventional commits

6.11. Experience Report Evidence#

redirect your history to a file log-2024-02-08.txt and include it with your experience report.

6.12. Questions After Today’s Class#

Important

Submit a question as an issue or a PR to this page

Contents