Why on all images that shows queue of commits in pro git book arrows leads to the opposite direction?
+1
A:
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.)
mipadi
2010-04-20 15:20:32
Correct - the contents of a commit object are the metadata (author, committer, message), the tree (internal representation of directory tree) of the commit, and the SHA1(s) of the parent commit(s). That is, a commit "points to" its parents (and not its children) via SHA1, exactly as the arrows show.
Jefromi
2010-04-20 15:24:29
This arrows made me crazy. Remains to understand why this information necessary for all images.
Orsol
2010-04-20 15:36:40
The arrows are helpful because you can tell a lot about the history by the arrows in the diagram. For example, look at commits C3, C4, and C5. Just from the arrows, we can tell that C3 and C4 share a common history beginning with C2 (i.e., they were each branched from C2), and C5 shows us that it is the result of the merge of C3 and C4, which means it contains the changes in both C3 and C4, as well as the common history of both those commits.
mipadi
2010-04-20 15:48:15
I mean that if there were just lines or arrows in other direction, that will be more natural
Orsol
2010-04-20 15:54:47
@Orsol the arrow direction is important for understanding why git can do some things easily (find ancestors of a commit, find common ancestors of several different commmits) and not other things (find all the children of any commit)- the tree walker (which forms the basis of many git commands) can only go with the flow.Still, I know how you feel. I've sworn a few times over about electron current being the reverse of conventional current...
araqnid
2010-04-20 23:12:40
+2
A:
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:
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.
VonC
2010-04-20 15:59:21