>>> "JCH" == Junio C Hamano <gitster@xxxxxxxxx> writes: > 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. Hm I realize that I understand git much less than I thought (I thought it is like mercurial, where git branches are mercurial bookmarks more or less). It turns out that this is not the case. Take the following part of what I did git init echo 1 > 1 git add 1 git commit -m 1 echo 1.1 > 1 git add . git commit -m 1.1 git checkout -b foo master~1 echo 1.2 > 1 git add . git commit -m 1.2 echo 1.2.1 > 1 git add . git commit -m 1.2.1 git checkout master There are 4 commits. But Git --log --graph --decorate Returns * commit 98922f82932cd1bef58bebf0229367922bca45fc (HEAD -> master) | Author: Uwe Brauer <oub@xxxxxxxxxx> | Date: Tue Aug 20 21:19:59 2019 +0200 | | 1.1 | * commit 8f565d59c356a6038e3d8a7f5dcd2e4a39ae1bb4 Author: Uwe Brauer <oub@xxxxxxxxxx> Date: Tue Aug 20 21:19:59 2019 +0200 If I would do the same with mercurial (either with bookmarks or with named branches) I receive hg init echo 1 > 1 hg add 1 hg commit -m 1 hg branch foo echo 1.1 > 1 hg add . hg commit -m 1.1 hg branch master echo 1.2 > 1 hg add . hg commit -m 1.2 echo 1.2.1 > 1 hg add . hg commit -m 1.2.1 hg checkout master @ changeset: 3:9ebcc17a6389 | branch: master | tag: tip | user: Uwe Brauer <oub@xxxxxxxxxx> | date: Tue Aug 20 21:27:05 2019 +0200 | summary: 1.2.1 | o changeset: 2:e02d297e2f75 | branch: master | user: Uwe Brauer <oub@xxxxxxxxxx> | date: Tue Aug 20 21:27:04 2019 +0200 | summary: 1.2 | o changeset: 1:7ddaef206d57 | branch: foo | user: Uwe Brauer <oub@xxxxxxxxxx> | date: Tue Aug 20 21:27:04 2019 +0200 | summary: 1.1 | o changeset: 0:dbf3c9975cf3 user: Uwe Brauer <oub@xxxxxxxxxx> date: Tue Aug 20 21:27:03 2019 +0200 summary: 1 Funny enough if I convert the git repo, to a hg repo either with hg convert or with hg clone (and the hg-git plugin) I receive a different graph o changeset: 3:e7b2696c94fb | bookmark: master | tag: tip | parent: 0:5dfd9027787a | user: Uwe Brauer <oub@xxxxxxxxxx> | date: Tue Aug 20 21:19:59 2019 +0200 | summary: 1.1 | | o changeset: 2:277f6423b9c8 | | bookmark: foo | | user: Uwe Brauer <oub@xxxxxxxxxx> | | date: Tue Aug 20 21:19:59 2019 +0200 | | summary: 1.2.1 | | | o changeset: 1:3529c82f37ae |/ user: Uwe Brauer <oub@xxxxxxxxxx> | date: Tue Aug 20 21:19:59 2019 +0200 | summary: 1.2 | o changeset: 0:5dfd9027787a user: Uwe Brauer <oub@xxxxxxxxxx> date: Tue Aug 20 21:19:59 2019 +0200 summary: 1 Anyhow, I don't want this message to be interpreted as a flamewar of sorts. I don't really know how the import functions work, but I see that git and mercurial treat commits which look simple to me very differently. Uwe Brauer
<<attachment: smime.p7s>>
