Wrong way arrows in GIT documentation

[the_emi_guy]

Anyone have any idea why the arrows in GIT workflow documentation are always drawn backwards?

For example, the logical way to diagram C4 and C5 merging to become C6 would be with arrows from C4 and C5 into C6, not the other way around.

 

[FactChecker]

The arrows are not showing the direction of evolution of the software. They are showing the dependencies of a version on prior versions.

 

[Filip Larsen]

From chapter 3 of the Pro Git book

When you make a commit, Git stores a commit object that contains a pointer to the snapshot of the content you staged. This object also contains the author’s name and email, the message that you typed, and pointers to the commit or commits that directly came before this commit (its parent or parents): zero parents for the initial commit, one parent for a normal commit, and multiple parents for a commit that results from a merge of two or more branches.

So in the tool you use, I would think the diagram show parent arrows because that is the direct information present for a version. You can of course flip the arrows in your head (or by using another tool perhaps) if you like, as long as you remember that behind the scene children points to parents and not the other way around.

 

[the_emi_guy]

The arrows are not showing the direction of evolution of the software. They are showing the dependencies of a version on prior versions.

But in GIT there are no dependencies on prior versions, GIT creates fully standalone snapshots of the code at each version (unlike ClearCase where only differences are recorded, so there are dependencies on prior versions).

In GIT, C4 and C5 are merged to form a standalone snapshot of the merged C6 that no longer depends on C4 or C5 for reconstitution.

In other areas of science and engineering arrows generally denote evolution when things are changed/combined to form new things (CH4 + 2O2 → CO2 + 2H2O).

So as a non-computer scientist who has had a need to learn GIT, I was just wondering if there is a good reason for showing the reverse.

 

[newjerseyrunner]

But in GIT there are no dependencies on prior versions, GIT creates fully standalone snapshots of the code at each version (unlike ClearCase where only differences are recorded, so there are dependencies on prior versions).

Sort of, but not really. It doesn't create a new snapshot of the entire repository, only the files that have changed. It works by creating hashes of the files, so if two files are the same between two different branches, they will point to the same file.

 

[FactChecker]

But in GIT there are no dependencies on prior versions,
So as a non-computer scientist who has had a need to learn GIT, I was just wondering if there is a good reason for showing the reverse.

As @Filip Larsen said, you can always flip the arrows in your mind, but there is are a couple of reasons for pointing backward. The first I am sure of and the second I am assuming:
1) As a programmer trying to document, debug, or understand a program, you need to know where the code you are looking at came from and why it is there. So you are tracing backward, all day, every day. As a working programmer, it is not nearly as often that you are looking at code and tracing forward to see what happened in later versions. (There might be hundreds of later versions.)
2) When you make a new version, you also make a new record that points back to the parents. That pointer record doesn't need to change later. So if two people download the same version for development, all the history would remain identical as their two versions diverged. If it pointed forward, the pointer record for a parent version would change every time a new version was derived from it. The data base would be less stable and it would be more difficult to compare and merge GIT depositories.

 

[the_emi_guy]

Sort of, but not really. It doesn't create a new snapshot of the entire repository, only the files that have changed. It works by creating hashes of the files, so if two files are the same between two different branches, they will point to the same file.

As @Filip Larsen said, you can always flip the arrows in your mind, but there is are a couple of reasons for pointing backward. The first I am sure of and the second I am assuming:
1) As a programmer trying to document, debug, or understand a program, you need to know where the code you are looking at came from and why it is there. So you are tracing backward, all day, every day. As a working programmer, it is not nearly as often that you are looking at code and tracing forward to see what happened in later versions. (There might be hundreds of later versions.)
2) When you make a new version, you also make a new record that points back to the parents. That pointer record doesn't need to change later. So if two people download the same version for development, all the history would remain identical as their two versions diverged. If it pointed forward, the pointer record for a parent version would change every time a new version was derived from it. The data base would be less stable and it would be more difficult to compare and merge GIT depositories.

Very good, thanks, I get it.

Thanks everyone.