Arrows direction in ProGit book

Question

Why on all images that shows queue of commits in Pro Git book arrows leads to the opposite direction?

Answer 1

It's to show the parent relationship. In Git, a particular commit knows about its parent(s), but not necessarily about its children. (Obviously that information can be derived based on the parent links, but I don't think it's stored directly in the commit object.)

Answer 2

The arrows reflects the direction followed by a DAG, Directed Acyclic Graph representing here the history of commits in Git (from most recent to oldest).

That representation is not a "perfect" one, as Eric Sink details in his article:

One of the coolest things about DAG-based version control tools is that the DAG is an expression of merge history. We interpret arrows in the DAG to mean "'I've got this".

So, when it comes time to do merge from 5b over to the (a) branch, we can use information in the DAG to know that 3b and 2b are already done

---

The same article details the limit of that representation:

Cherrypicking

But a DAG is just one implementation of merge history, and it is definitely not perfect.

An arrow in a version control DAG goes from child to parent. It tells us that the child contains all of the changes in the parent. And its grandparents. And its great grandparents. And so on.

But what if this isn't true?

Consider the following picture:

I want to create changeset 4.
I want to start at changeset 1, and then I want to apply the changes from changeset 3, but NOT the stuff in changeset 2.
This operation is sometimes called "cherrypicking". I don't want to merge all changes from one branch to another. I just want to pluck one changeset (or one part of a changeset) and apply it as a patch to some other place.

How do I represent this in the DAG?

I can't.

• I could draw an arrow from 4 to 3 (shown above in red). This would correctly say that 4 contains the changes in 3, but it would INCORRECTLY claim that 4 contains the changes in 2.
• OR, I could draw no arrow. Effectively, my merge history would simply not record the fact that 4 is really 3 converted to a patch and applied to 1.

In either case, something bad is going to happen next time I merge from one branch to the other:

• If I draw that lying arrow, I will not be given the chance to apply changeset 2, because the merge history believes I already did it.
• If I don't draw any arrow, the tool will expect me to deal with changeset 3, because there is no merge history recording the fact that I already did it.

Neither of these problems is disastrous enough to make the evening news, but still.

That is why a rebase is never far after a cherry-pick operation, in order to get back a more classic DAG.