- #1
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.
FactChecker said:The arrows are not showing the direction of evolution of the software. They are showing the dependencies of a version 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.the_emi_guy said: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).
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:the_emi_guy said: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.
newjerseyrunner said: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 said: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.
Wrong way arrows in GIT documentation refer to the direction of the arrows used in diagrams to represent the flow of commits and changes in a GIT repository. The arrows point from newer commits to older commits, so if an arrow is pointing in the opposite direction, it is considered a "wrong way" arrow.
Wrong way arrows are important because they help users understand the chronological order of commits and changes in a GIT repository. This can be helpful when trying to troubleshoot or understand the history of a project.
Wrong way arrows cannot be "fixed" as they are simply a representation of the chronological order of commits. However, if you notice that the arrows in your repository are consistently pointing in the wrong direction, it may be a sign of a larger issue with your workflow or repository structure.
No, wrong way arrows are not always a problem in GIT documentation. In some cases, they may be intentional, such as when merging branches or reverting changes. However, if you consistently see wrong way arrows in your repository, it may be worth investigating further to ensure proper version control practices are being followed.
No, the direction of arrows in GIT documentation cannot be changed. They are a standard representation used to depict the chronological order of commits and changes in a GIT repository.