Git record parental order

Question

Is there any agreement for the order of parental fixators?

Since one of the parent-latches must be associated with the previous commit of the current branch, which is merged, and the rest are previous commits of other merging branches.

I would like to identify the previous commit of the current branch , I use pygit , which returns a list of parents for the commit, and intuitively I thought that maybe the order of the parents matters, but I did not find an explicit mention of this.

---

I wrote this utility function using the first parent commit to branch into:

 def walk_branch(pygit_repository, branch_oid): """ Walk a single branch """ from pygit2 import GIT_SORT_TOPOLOGICAL previous_first_parent_oid = None for commit in pygit_repository.walk(branch_oid, GIT_SORT_TOPOLOGICAL): if previous_first_parent_oid is None or commit.oid == previous_first_parent_oid: previous_first_parent_oid = commit.parents[0].oid if len(commit.parents) else None yield commit 

Answer 1

libgit2 , and its bindings are returned to the parents in the order in which they are stored in the commit, which is the order of the commits as they were specified, for example. command line for git merge , and this is constant when the first parent is the current git commit when creating a new one (either via merge or regular git commit ).

To identify the commit of the previous commit (by time), all you have to do is look at the first parent. Whether they are in the same branch or not, this is not what you can see from this, since the parent-latch can be in another branch (which causes the branches), but you can draw a straight line (for example, those git log --graph --oneline draws).

Answer 2

Yes, if you combine A into B, the first parent is B and the second will be A.

Therefore, you can do things like gitk --first-parent to show only the history of the current branch without details about the merge branches.

Answer 3

Any parent after the first parent is a merge from another branch with at least one exception.

If you combine a branch into yourself, which usually happens when it is processed in two places separately and then integrated, one of these “branches” in the branches will appear as if it comes from nowhere.

This will be displayed if you go through all the parents of all branches of the leaf, but such branches inside the branches will not appear if you go through the linear history of all branches of the leaf. This is at least still true in the sense that you will only go through the linear history of the commits that have been merged. What will be hidden is the fact that there is a branch inside the branch, so it will not show the entire history exclusive to this branch.

I don't know if branch removal has the same effect.