Merging
git merge feature sometimes writes a brand-new commit and sometimes writes nothing at all, just nudges a pointer. Same command, same two branches, two different results on disk, and one check decides which.
- ▸The same
git mergeeither writes a new commit or writes nothing, and a reachability check, not you, picks which. - ▸Merging two branches that both moved builds one commit that points back at two parents at once.
- ▸Merge from the other branch and the parent order flips, changing which line reads as the trunk.
You run git merge feature in two different repos and get two different kinds of result. In one, a new commit shows up in the log. In the other, nothing new is created, your current branch just ends up pointing at the exact commit feature already pointed at.
The command did not behave randomly. Before writing anything, git merge walks backward through parent links. First it starts from the commit you are on: can that walk reach feature's tip? If it can, feature holds nothing you lack: git prints Already up to date. and writes nothing.
If not, it walks the other way, from feature's tip: can that walk reach the commit you are on? If yes, the branch you are on is simply behind. Everything on your branch is already on feature's path, so there is nothing to bring together and git takes the cheap route.
Only when neither walk reaches the other tip have the two branches moved apart, each holding commits the other cannot reach by walking parents. Now there really are two sets of changes to combine, and git takes the expensive route.
The viz lets you push each branch forward by adding commits, then runs those walks and reports the verdict. The whole topic is those two routes: what each one writes, and why this single check, not the command you typed, decides between them.