Re: [PATCH 0/1] Preserve topological ordering after merges

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Derrick,

Thank you for your comments!

08.01.2020 16:37, Derrick Stolee wrote:
On 1/8/2020 7:50 AM, Sergey Rudyshin wrote:
let me explain in more detail why I thought it would make sense to stop using "--topo-order".
in case if a user specifies a single commit, like this
git rev-list E
with a new algorithm the options "--date-order", "--author-date-order", "--topo-order" do not change the ordering. Because there is only one way to sort any git graph with a single tip.

This is false, unless your history is always linear (no merge commits).

Would it be possible to provide some test script which would prove you point? We could run it against the binary created based from https://github.com/gitgitgadget/git/pull/514/commits/542a02020c8578d0e004cb9c929bced8719b902a



in case if a user specifies multiple tips, like this
git rev-list --topo-order C B ^A
current version of git displays commits ordered by commit timestamp
which does not seem like a topological ordering.

Are you talking about which of C and B are shown first? They are shown in an order based on your input. If C and B are independent (neither can reach the other), then they will swap order if you write "git rev-list --topo-order B C ^A".


Please find a script showing that commits are always sorted by commit timestamp no matter how they appear in the input.

$ cat ./test.sh
#!/bin/bash
export LANGUAGE=en
GIT=/usr/bin/git
$GIT --version
rm -rf .git
$GIT init
export GIT_COMMITTER_DATE="2000-01-01T00:00:00 +0000"
$GIT commit -m "0" --allow-empty
$GIT tag 0
export GIT_COMMITTER_DATE="2001-01-01T00:00:00 +0000"
$GIT checkout --orphan b1
$GIT commit -m "1" --allow-empty
$GIT tag 1
export GIT_COMMITTER_DATE="2002-01-01T00:00:00 +0000"
$GIT checkout --orphan b2
$GIT commit -m "2" --allow-empty
$GIT tag 2

fnc () {
	echo "$@"
$GIT log --graph --pretty=tformat:"%D %ci" "$@" | sed 's/-01-01 00:00:00 +0000//'
}
fnc --topo-order 0 1
fnc --topo-order 1 0

fnc --date-order 0 1
fnc --date-order 1 0

fnc --topo-order 1 2
fnc --topo-order 2 1

fnc --date-order 1 2
fnc --date-order 2 1

fnc --topo-order 0 1 2
fnc --topo-order 2 1 0

$ ./test.sh
git version 2.7.4
Initialized empty Git repository in /tmp/git_test_case_ordering/.git/
[master (root-commit) 0a449fc] 0
Switched to a new branch 'b1'
[b1 (root-commit) 070d07f] 1
Switched to a new branch 'b2'
[b2 (root-commit) c751327] 2
--topo-order 0 1
* tag: 1, b1 2001
* tag: 0, master 2000
--topo-order 1 0
* tag: 1, b1 2001
* tag: 0, master 2000
--date-order 0 1
* tag: 1, b1 2001
* tag: 0, master 2000
--date-order 1 0
* tag: 1, b1 2001
* tag: 0, master 2000
--topo-order 1 2
* HEAD -> b2, tag: 2 2002
* tag: 1, b1 2001
--topo-order 2 1
* HEAD -> b2, tag: 2 2002
* tag: 1, b1 2001
--date-order 1 2
* HEAD -> b2, tag: 2 2002
* tag: 1, b1 2001
--date-order 2 1
* HEAD -> b2, tag: 2 2002
* tag: 1, b1 2001
--topo-order 0 1 2
* HEAD -> b2, tag: 2 2002
* tag: 1, b1 2001
* tag: 0, master 2000
--topo-order 2 1 0
* HEAD -> b2, tag: 2 2002
* tag: 1, b1 2001
* tag: 0, master 2000



so I decided to change the documentation so that "--topo-order" and "--date-order" be the same. And since "--topo-order" does not add anything new decided to deprecate it.

Based on this sentence, it is clear that you do not understand the difference between --topo-order and --date-order. Please take time to examine the output difference for the Git repo with the following commands:

	git log --oneline --graph --topo-order
	git log --oneline --graph --date-order


Hope that the script above will clarify what i meant.

Regarding the failed test
I'll try to find the reason but what puzzles me is why those tests (t4202, t4215 and t6012) succeeded on all other platforms (linux32, osx-clang, windows, ...) and only failed on linux-gcc.
In my machine those tests do not fail either (gcc (Ubuntu 5.4.0-6ubuntu1~16.04.12) 5.4.0 20160609)

Try running the tests with GIT_TEST_COMMIT_GRAPH=1.


Yes it helped. With that option the tests starts to fail.
I'll try to find out how COMMIT_GRAPH works and fix it.

-Stolee

PS
excluded Junio from the loop per his request.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux