3 ms·

> It is also true that many git commands implictly treat a commit as being the diff between the state of the tree in that commit and the state in the parent. Fo

> It is also true that many git commands implictly treat a commit as being the diff between the state of the tree in that commit and the state in the parent. For example git show, git rebase and git cherry-pick. A commit is a snapshot, and you can compute the diff between a commit and any of its parents. If a commit has multiple parents, git cherry-pick bails out unless you pick a parent (usually -m 1), and git rebase, I think implicitly assumes the first parent. (EDIT: a commit's tree, its parents' trees)

LukeShu 6y ago
> If a commit has multiple parents, … git rebase, I think implicitly assumes the first parent. `git rebase`'s behavior regarding merge commits is shockingly complicated, but much of the time: Because by default it linearizes the history, it actually just skips merge commits because it assumes that the merge has already happened implicitly by applying one of the merge's parents on top of the other parent.