* Re: [problem with name-rev] (was: git log --graph with a sort of local revision number)
2019-08-20 14:32 ` [problem with name-rev] " Uwe Brauer
@ 2019-08-20 15:06 ` SZEDER Gábor
2019-08-20 17:49 ` Rafael Ascensão
2019-08-20 18:21 ` [problem with name-rev] Junio C Hamano
2 siblings, 0 replies; 13+ messages in thread
From: SZEDER Gábor @ 2019-08-20 15:06 UTC (permalink / raw)
To: Uwe Brauer; +Cc: Rafael Ascensão, git, Alban Gruin
On Tue, Aug 20, 2019 at 04:32:12PM +0200, Uwe Brauer wrote:
> Here's what I get when I start committing on master, then switch to a
> branch foo and finally merge foo into master:
> * 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.
What exactly do you think looks odd? That "master^2~1", perhaps?
That's how commits on different branches are named, see 'man
gitrevisions', and 'git name-rev' works as designed.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [problem with name-rev] (was: git log --graph with a sort of local revision number)
2019-08-20 14:32 ` [problem with name-rev] " Uwe Brauer
2019-08-20 15:06 ` SZEDER Gábor
@ 2019-08-20 17:49 ` Rafael Ascensão
2019-08-20 18:21 ` [problem with name-rev] Junio C Hamano
2 siblings, 0 replies; 13+ messages in thread
From: Rafael Ascensão @ 2019-08-20 17:49 UTC (permalink / raw)
To: Uwe Brauer; +Cc: git, Alban Gruin
On Tue, Aug 20, 2019 at 04:32:12PM +0200, Uwe Brauer wrote:
>
> It seems that there is problem with name-rev.
>
In git, branches are just pointers to a commits. Commits do not store
any information about branches. They're similar to mercurial bookmarks.
Thus, git is not able to answer "Was commit X was made in branch Y?".
What that command does is describe each entry in the log in function of
your active branch. Keep in mind that these descriptions are relative,
and they'll change as you make more commits.
It is basically asking git the following:
"Is commit X (each log entry) an ancestor of the commit pointed by
branch Y? (HEAD, meaning your active branch) If yes, describe the
relationship between them"
Considering your example,
* 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
| |
54c9230 is the parent (~1) of master's second parent (master^2).
If you make an additional commit on master, the same 54c9230 will be
described as master~1^2~1
Check the documentation to learn the syntax: git help revisions
If want a permanent reference for a commit, you'll need to:
1) Use an unambiguous prefix of the commit ID.
2) Make a tag to the commit you want to reference.
Cheers,
Rafael Ascensão
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [problem with name-rev]
2019-08-20 14:32 ` [problem with name-rev] " Uwe Brauer
2019-08-20 15:06 ` SZEDER Gábor
2019-08-20 17:49 ` Rafael Ascensão
@ 2019-08-20 18:21 ` Junio C Hamano
2019-08-20 19:34 ` Uwe Brauer
2 siblings, 1 reply; 13+ messages in thread
From: Junio C Hamano @ 2019-08-20 18:21 UTC (permalink / raw)
To: Uwe Brauer; +Cc: Rafael Ascensão, git, Alban Gruin
Uwe Brauer <oub@mat.ucm.es> 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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [problem with name-rev]
2019-08-20 18:21 ` [problem with name-rev] Junio C Hamano
@ 2019-08-20 19:34 ` Uwe Brauer
2019-08-20 19:57 ` Phil Hord
0 siblings, 1 reply; 13+ messages in thread
From: Uwe Brauer @ 2019-08-20 19:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Uwe Brauer, Rafael Ascensão, git, Alban Gruin
[-- Attachment #1: Type: text/plain, Size: 4658 bytes --]
>>> "JCH" == Junio C Hamano <gitster@pobox.com> writes:
> Uwe Brauer <oub@mat.ucm.es> 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@mat.ucm.es>
| Date: Tue Aug 20 21:19:59 2019 +0200
|
| 1.1
|
* commit 8f565d59c356a6038e3d8a7f5dcd2e4a39ae1bb4
Author: Uwe Brauer <oub@mat.ucm.es>
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@mat.ucm.es>
| date: Tue Aug 20 21:27:05 2019 +0200
| summary: 1.2.1
|
o changeset: 2:e02d297e2f75
| branch: master
| user: Uwe Brauer <oub@mat.ucm.es>
| date: Tue Aug 20 21:27:04 2019 +0200
| summary: 1.2
|
o changeset: 1:7ddaef206d57
| branch: foo
| user: Uwe Brauer <oub@mat.ucm.es>
| date: Tue Aug 20 21:27:04 2019 +0200
| summary: 1.1
|
o changeset: 0:dbf3c9975cf3
user: Uwe Brauer <oub@mat.ucm.es>
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@mat.ucm.es>
| date: Tue Aug 20 21:19:59 2019 +0200
| summary: 1.1
|
| o changeset: 2:277f6423b9c8
| | bookmark: foo
| | user: Uwe Brauer <oub@mat.ucm.es>
| | date: Tue Aug 20 21:19:59 2019 +0200
| | summary: 1.2.1
| |
| o changeset: 1:3529c82f37ae
|/ user: Uwe Brauer <oub@mat.ucm.es>
| date: Tue Aug 20 21:19:59 2019 +0200
| summary: 1.2
|
o changeset: 0:5dfd9027787a
user: Uwe Brauer <oub@mat.ucm.es>
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 #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5025 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [problem with name-rev]
2019-08-20 19:34 ` Uwe Brauer
@ 2019-08-20 19:57 ` Phil Hord
2019-08-21 7:50 ` Uwe Brauer
0 siblings, 1 reply; 13+ messages in thread
From: Phil Hord @ 2019-08-20 19:57 UTC (permalink / raw)
To: Uwe Brauer; +Cc: Junio C Hamano, Rafael Ascensão, Git, Alban Gruin
On Tue, Aug 20, 2019 at 12:35 PM Uwe Brauer <oub@mat.ucm.es> wrote:
>
> 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@mat.ucm.es>
> | Date: Tue Aug 20 21:19:59 2019 +0200
> |
> | 1.1
> |
> * commit 8f565d59c356a6038e3d8a7f5dcd2e4a39ae1bb4
> Author: Uwe Brauer <oub@mat.ucm.es>
> Date: Tue Aug 20 21:19:59 2019 +0200
Try adding '--all' to include all refs, not just the current HEAD, to
begin logging from. Here is what I see after running your setup
script.
$ git log --graph --decorate --all
* commit 3262040f2d8d5f31b4918bda9987e6b5f788531f (foo)
| Author: Phil Hord <phord@purestorage.com>
| Date: Tue Aug 20 12:44:32 2019
|
| 1.2.1
|
* commit fc66c4311bf954d455f468581f2913dffa0f9c2b
| Author: Phil Hord <phord@purestorage.com>
| Date: Tue Aug 20 12:44:32 2019
|
| 1.2
|
| * commit 109e5d4baef4e99cf636189ba1499af817ab0bb1 (HEAD -> master)
|/ Author: Phil Hord <phord@purestorage.com>
| Date: Tue Aug 20 12:44:32 2019
|
| 1.1
|
* commit 5c1e93ed7c5b3b241d5adfadb365a6bca5d60d3a
Author: Phil Hord <phord@purestorage.com>
Date: Tue Aug 20 12:44:32 2019
1
You could also mention only the refs you are interested in instead of
including all of them.
$ git log --graph --decorate foo master
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [problem with name-rev]
2019-08-20 19:57 ` Phil Hord
@ 2019-08-21 7:50 ` Uwe Brauer
2019-08-21 12:37 ` Uwe Brauer
0 siblings, 1 reply; 13+ messages in thread
From: Uwe Brauer @ 2019-08-21 7:50 UTC (permalink / raw)
To: Phil Hord
Cc: Uwe Brauer, Junio C Hamano, Rafael Ascensão, Git,
Alban Gruin
[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]
> On Tue, Aug 20, 2019 at 12:35 PM Uwe Brauer <oub@mat.ucm.es> wrote:
> Try adding '--all' to include all refs, not just the current HEAD, to
> begin logging from. Here is what I see after running your setup
> script.
> $ git log --graph --decorate --all
> * commit 3262040f2d8d5f31b4918bda9987e6b5f788531f (foo)
> | Author: Phil Hord <phord@purestorage.com>
> | Date: Tue Aug 20 12:44:32 2019
> |
> | 1.2.1
> |
> * commit fc66c4311bf954d455f468581f2913dffa0f9c2b
> | Author: Phil Hord <phord@purestorage.com>
> | Date: Tue Aug 20 12:44:32 2019
> |
> | 1.2
> |
> | * commit 109e5d4baef4e99cf636189ba1499af817ab0bb1 (HEAD -> master)
> |/ Author: Phil Hord <phord@purestorage.com>
> | Date: Tue Aug 20 12:44:32 2019
> |
> | 1.1
> |
> * commit 5c1e93ed7c5b3b241d5adfadb365a6bca5d60d3a
> Author: Phil Hord <phord@purestorage.com>
> Date: Tue Aug 20 12:44:32 2019
> 1
That's it, thanks. Interestingly enough the
git graph looks differently from the mercurial one.
The mercurial one looks purely linear (with two branches) while the git one is not,
but maybe it is not clear to me who to translate the git command
git checkout -b foo master~1
To mercurial?
Anyhow the original question was about having a sort of local revision
number and I see that this is somehow possible, which was not clear to
me before.
Thanks
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5025 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread