This was the Holy Grail as of 2023, when text-to-image started to really take off, but text-to-video was miles behind.
- medium.com/@chain.info1/the-mystery-behind-satoshi-tribute-donations-cf4ce28c56a1 The Mystery Behind "Satoshi Tribute" Donations by Chain.Info (2020)
This is the most important thing to understand Git!
You must:
- be able to visualize the commit tree
- understand how each git command modifies the commit DAG
It's not a tree, it's actually a DAG by 
Ciro Santilli 35 Updated 2025-04-05 +Created 1970-01-01
Ciro Santilli 35 Updated 2025-04-05 +Created 1970-01-01Every tree is a directed acyclic graph.
But not every directed acyclic graph is a tree.
Example of a tree (and therefore also a DAG):Convention in this presentation: arrows implicitly point up, just like in a and so on.
5
|
4 7
| |
3 6
|/
2
|
1git log, i.e.:- 1 is parent of 2
- 2 is parent of 3 and 6
- 3 is parent of 4
Example of a DAG that is not a tree:This is not a tree because there are two ways to reach 7:
7
|\
4 6
| |
3 5
|/
2
|
1- 2, 3, 4, 7
- 2, 5, 6, 7
But we often say "tree" intead of "DAG" in the context of Git because DAG sounds ugly.
Example of a graph that is not a DAG:This one is not acyclic because there is a cycle 2, 3, 4, 5, 2.
6
^
|
3->4
^ |
| v
2<-5
^
|
1Because a Git commit can have more than 1 parent due to merge commits when you do:
git mergeIt can even have more than 2, there's no limit. Although that is not so common (with good reason, 2 is already one too many): softwareengineering.stackexchange.com/questions/314215/can-a-git-commit-have-more-than-2-parents/377903#377903
There are two ways to organize a project:
- linear history
- branched history: history with merge commits
Some people like merges, but they are ugly and stupid. Rebase instead and keep linear history.
Linear history:
5 master
|
4
|
3
|
2
|
1 first commitBranched history:
7 master
|\
| \
6 \
|\ \
| | |
3 4 5
| | |
| / /
|/ /
2 /
| /
1/ first commitHere commits 6 and 7 are the so called "merge commits":
- they have multiple parents:
- 6 has parents 3 and 4
- 7 has parents 5 and 6
- they are useless and don't contain any real information
Which type of tree do you think will be easier to understand and maintain?
????
????????????
You may disconnect now if you still like branched history.
Generate a minimal test repo. You should get in the habit of doing this to test stuff out.
#!/usr/bin/env bash
mkdir git-tips
cd git-tips
git init
for i in 1 2 3 4 5; do
echo $i > f
git add f
git commit -m $i
done
git checkout HEAD~2
git checkout -b my-feature
for i in 6 7; do
echo $i > f
git add f
git commit -m $i
doneOption 1)
git commit. Doh!!!Option 2)
git rebase. Basically allows you to do arbitrary modifications to the tree. The most important ones are: Oh, but there are 2 trees: local and remote by Ciro Santilli 35 Updated 2025-04-05 +Created 1970-01-01
Ciro Santilli 35 Updated 2025-04-05 +Created 1970-01-01Oh but there are usually 2 trees: local and remote.
So you also have to learn how to observe and modify and sync with the remote tree!
But basically:to update the remote tree. And then you can use it exactly like any other branch, except you prefix them with the remote (usually
git fetchorigin/*), e.g.:origin/masteris the latest fetch of the remote version ofmasterorigin/my-featureis the latest fetch of the remote version ofmy-feature
gitk 2.34.1 running on Ubuntu 22.04 with a simple repository.
GNU Core Utils command line utility by Ciro Santilli 35 Updated 2025-04-05 +Created 1970-01-01
Ciro Santilli 35 Updated 2025-04-05 +Created 1970-01-01Non-POSIX only here.
The best open source implementation as of 2020 seems to be: Mozilla rr.
There are unlisted articles, also show them or only show them.