Uwe Brauer <oub@xxxxxxxxxx> writes: > Gives > * changeset: ae68dbe:master > |\ user: Uwe Brauer > | | date: Tue Aug 20 16:25:53 2019 +0200 > | | summary: 1.2.1/1.1 > | | > | * changeset: c00bb5d:master^2 > | | user: Uwe Brauer > | | date: Tue Aug 20 16:25:53 2019 +0200 > | | summary: 1.2.1 > | | > | * changeset: 54c9230:master^2~1 > | | user: Uwe Brauer > | | date: Tue Aug 20 16:25:53 2019 +0200 > | | summary: 1.2 > | | > * | changeset: da0712f:master~1 > |/ user: Uwe Brauer > | date: Tue Aug 20 16:25:53 2019 +0200 > | summary: 1.1 > | > * changeset: 8eb999d:master~2 > user: Uwe Brauer > date: Tue Aug 20 16:25:53 2019 +0200 > summary: 1 > > That looks odd. > > Any comments? When you make a merge like the ae68dbe, merging a topic with two commits 54c9230 and c00bb5d into the then-current tip of the master branch da0712f, _all_ direct parents are recorded in the resulting merge commit, so the first parent of it is denoted as ae68dbe~1 (which is da0712f) and the second parent of it ae68dbe^2 (which is c00bb5d). There is no linear ordering between these two commits, so c00bb5d will *never* be named as master~<some-number>. As a commit on a side branch, its description from the tip of 'master' will always involve some ^2 (the second parent of some merge commit) somewhere in its name-rev result. If you are saying that the $commit^$nth_parent notation "looks odd", then you are shooting the messenger with your title. The problem is not with name-rev; the problem is with the way the world works.
