My Cheatsheet on magit

Git models history as a collection of files and folders within a top-level directory.

For example, given this tree structure on a Linux host:

tree .
     .
     ├── ansible-logo.png
     └── foo
	 └── bar.txt

Git labels them as follows:

• "tree" is a folder so in this case, foo is a "tree" as is . the root tree is a "tree"
• "blob" is a file, so in this case, bar.txt is a "blob"

So trees can contain blobs and other trees. But blobs cannot contain trees.

The top level tree is the directory that is being tracked by git.

The history gives a the complete folder structure at any given point in time. Now, you might think that the version history is just a linear sequence of snapshots. But git is more sophisticated than that. It models the history as a directed acyclic graph to model the history.

Each snapshot has some number of parents. Each parent may have more than one child.

here is git's model of history using pseudo code. It has three types, blobs, trees, and commits. All git objects are one of these 3 types.

type blob = array<bytes>  # an array of bytes.  i.e. it is a file.
type tree = map<string, tree | blob >  # a folder, which is a mapping from
                                       # the filename or dictory name to the
				       # contents, which is either another
				       # tree (i.e. a subtree) or the file

type commit = struct {        # a snapshot, that is what git calls a commit.
     parents: array<commit>   # an array of commits
                              # not the actual commit, but pointers to the
			      # commits.
     author: string           # more metadata for this commit
     message: string
     snapshot: tree           # is the actual contents of the commit which
     }                        # is the snapshot itself, ie the top level tree
                              # corresponding to a particular commit.

This psuedo code comes from this youtube link.

see git.org file in this directory for more on this topic.

If you create a new program in the main repository, git will not itself start tracking changes to this program. Easy to confirm by touching a new file, and running git status You will see the "untracked" new file.

should show the file as "modified", under "Changes not staged for commit:"

Also git add -A to add all the files in the local directory

should now show the file under "Changes to be committed"

Asks for you to edit a note explaining the changes, then commits them

Will create a local copy of the files in the repository into the local dir.

git diff filename will show you what has changed in the file specified, compared to the file as saved in the last commit (i.e. snapshot). Or, more accurately, git diff filename compares current filename to the filename pointed to by HEAD.

for example git show 2097655d8d0d1737a0da7f27ff07d78e797c89e8

refernces = map<string, string> Where you create a map of the 40 character hex sting to a human readable string.

The strings are what you write in a commit. A reference is also called a "pointer" They are the same thing.

git checkout moves the head pointer AND modifies the current directory so that it matches exactly the "snapshot" or commit that was checked out.

This is actually a shortform for two commands:

1. git branch covid-19
2. git checkout covid-19

You can create custom references, which as all other references are, are simply labels attached to a git hash.

pulls down the files from the git repository beware that working dir files are overwritten. (See git fetch)

will send the locally modifed file to the git repository

The workflow is:

You will see the files, the magit status, and the current command windows that will show you your 1) options for the command, and the 2) actions to perform if the command has multiple actions that are possible. For instance hitting c will get you a commit command window at which point you will see multiple options, including another c for confirm commit. So you can get used to hitting cc as a usual, vanilla commit.

• q quit this command (magit-log-bury-buffer) (closes the buffer)
  • <tab> to expand sections OR to expand a file magit-section-toggle
• hammer magit-visit-thing ?
• s on an untagged file, (or untracked??) to stage it. magit-stage
• u on a stagged file to unstage it. magit-unstage
• i ignore this file is added to the .gitignore file.
• ? show available commands. magit-dispatch also h
• q to quit this command display
• k discard this file (deletes it) magit-discard
• c commit magit-commit
• c commit magit-commit-create (c is entered twice )
• b branch magit-branch
• b b again which is magit-checkout ( b is entered twice ) similar to a git checkout -b
• C-n and C-p next and previous line (or use arrow keys)
• M-n and M-p next and previous sibling section. Siblings are at the same level, i.e. from top down they are:
  • section
  • file
  • changed block
  • line
• g to refresh the window
• rm there is no magit command that matches git rm but you can simply stage the unstagged deletes, then commit and you will be done with the list of deleted files.
• s spin off a branch magit-branch-spinoff
• l log magit-log
• l log magit-log-current (l is entered twice)
• w magit-am
• w magit-am-apply-patches (w is entered twice)
• C-c C-c to close the edited commit.
• SPC show a magit diff magit-diff-show-or-scroll-up
• 0 show magit diff default magit-diff-default-context
• 1 show section level 1
• 2 show section level 2
• 3 show section level 3
• 4 show section level 4
• : magit-git-command
• < beginning of buffer
• > end of buffer

So a typical, basic magit workflow is: M-x magit

• TAB on any file you want to look at the diff. ( yas-expand )
• s -
• s |- or all changes with S
• s -
• k
• k - discard three files
• k
• i - ignore
• c c - commit

Make your editing changes, then C-c C-c actually I think it's C-c c Find out which one. It is C-c C-c for "editing-complete" or so. ?

• $ bring up the details of the error message that just appeared. This is very useful if the command you just ran got an error. Get used to $
• P push your commit o repository i.e. github (or local repository if you have that set up in another directory, possibly and external drive?

  i.e. once you have done your latest commit, you can simply hit P to push that commit to your remote repository.

There is a pedantic, but good youtube video on a magit workflow.

M-x magit-status (you can set C-x g to map to M-x magit-status by using: (global-set-key (kbd "C-x g") 'magit-status) in your .emacs-d/init file

Refres (g/G) global-magit-file-mode (C-c M-g) magit-dispatch (C-x M-g)

First a good idea to confirm that C-x g is not being used by anything useful C-h k C-x g See help magit status section above.

? will display the magit commands availale. (must be in the magit-status buffer)

M-n/p, j to move around the git status window (next/previous) M-1 or -2 or -3 or -4 , TAB, S-<tab> for visibility (or just use up and down)

D C-c C-t (or M-x magit-diff-trace-definition) ?

Once in the diff buffer (D) see toggles such as -U for context lines and -t for hunk refinements which can show you the actual changes made to files between git commits.

git diff –word-diff (is the equivalent git cli command.

In a diff buffer, you can get the function history list as well… That is a list of historic changes to the function you are currently looking at say in python, or in .php or whatever program is being edited in magit mode.

L can toggle dates from absolute dates or days or hours ago.

shows who and when people committed people.

$ will show you what is happening with your git commands, at any time you want.

• to show dates when lines or sections were added or changed or deleted from a git file.

c

• e allow empty commit
• a stage all modified and deleted files –all
• v show diff of changes to be committed
• M-n or M-p can browse through past commit messages. (once in the commit buffer) i.e. have hit c Of course arrow keys up and down work as well as M-n and M-p

You can also C-c C-a to commit ammend (see docs for all the options of C-c C-a to commit ammend.)

b brings up the branch popup. Can create a new branch, or open a branch, can check it out or not in the same command.

V VV (magin-revert-and-commit) Vv (magit-revert-no-commit)

Read the docs on this. What follows is just to make you aware that this feature exists, and is fairly useful:

Get your mouse onto a recent commit (pick one) and hit: x (and type Head) to revert to that version. ? x (and bring up the log to see what version you want to revert to.)

z z (magit-stash-both) Stashes index and working tree, untracked files included.

Once a change is stashed, you can hit a on the stash (under git status buffer) at a latter time, to then incorporate the change into the branch at that time.

r i (magit-rebase-interactive) Rebase allows you to resolve conflicts and rewrite history. * very useful

magit does this very well.

Look at the log, choose a commit where you want to start the rebase. hit r i For instance c76309r then you will see a list of commands. Read them and use C-c C-c to execute what you want with the rebase. - any errors will pop up for you to resolve, or skip and continue forward.

C-c C-k to kill buffer out of this if you do not want to make any changes.

B B (magit-bisect-start) B s (magit-bisect-run) B b (magit-bisect-bad) B g (magit-bisect-good) B r (magit-bisect-reset)

This is good if you have a bug and want to know when the bug came into being.

Works good if you have been following proper git ettiquette, hygene and standards, with proper messages left on commits, etc.

Read up on this.