• First line: "when applied, this commit will…" (50 char limit)
  • Can become subject line of an email
  • text like "[PATCH linux-usb v2 0/13]" may get added to the beginning
• Second line empty
• Commit description at 72 columns (standard width of email)
  • rationale for the change
  • trade-offs and limitations of the approach

git-subrepo is an alternative to git submodule and git subtree.

With a subrepo, operations on the main repo (e.g. cloning or commiting) work transparently without the need of extra commands or the need of git-subrepo as a dependency. Only when needing to push to the remote subrepo or pulling into the local subrepo you need to use below commands (and git-subrepo needs to be installed).

How to use:

• While in main git repo, clone a remote repo as a subrepo git subrepo clone <remote-url> [<subdir>]
• Push/pull changes with git subrepo push/pull

Git provides tools for collaborating over email. This way, patches can be submitted, applied and talked about in an email chain.

See

• https://git-send-email.io/
• https://drewdevault.com/2018/07/02/Email-driven-git.html
• https://begriffs.com/posts/2018-06-05-mailing-list-vs-github.html

See

• https://jvns.ca/blog/2023/11/01/confusing-git-terminology/
• https://roadrunnertwice.dreamwidth.org/596185.html

Most things in git are pointers to commits: branch names, HEAD, tags.

• Commits:
  • Unique and immutable, and are anchored to a specific point in the graph of history and causality.
  • A commit's identity is made up of both its content and its context. (If a commit has the same content but a different parent, it's NOT the same commit.)
  • Git commits are stored on disk as snapshots, but that's not necessarily how Git treats them!
  • Various Git commands treat a commit as either a complete repo snapshot or as a change set, depending on what you’re doing.
  • (The patch version of a commit isn’t stored anywhere persistent, but is instead derived at need by comparing against its parent(s).)
  • For example, commands like cherry-pick or revert treat commits like patches. show treats commits as both, depending on its arguments!
  • Novice Git users tend to have a hard time understanding whether they’re trying to treat a commit as a snapshot or a patch, which adds some extra difficulty to formulating reliable plans.
• HEAD: Points to the commit you're currently looking at
• Branch name: e.g. my-feature points to the latest commit of that branch
• detached HEAD: Commit you're looking at is not pointed at by any branch.
• Tags: Point to a specific commit and do not move (unlike branches).
• Most git commands assumes default arguments:
  • git checkout file.txt is the same as git checkout HEAD -- file.txt
  • When on my-branch, git rebase main is the same as git rebase main my-branch
• Creating a commit adds to the top and updates the HEAD and my-branch pointer
• git reflog: Shows all the commits that HEAD has pointed to
• files=blobs (named after the SHA1 hash of its content),
• dirs=trees=collections of blobs+trees (named after the SHA1 hash of its content),
• a commit=top-level tree + parent commit(s) + commit comment (named after the SHA1 hash of its content).
• A branch is a reference/pointer to the latest commit in a series.

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ *, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.

See https://trunkbaseddevelopment.com/

• Start with Chapter 10 of Pro Git, then read ch. 2, 3, and 7. Rest is optional.
• Oh Shit, Git - Fixing common mistakes
• Flight rules for git
• Git Glossary