Re: git: uh-oh

Поиск
Список
Период
Сортировка
От Aidan Van Dyk
Тема Re: git: uh-oh
Дата
Msg-id 20100820205724.GA26180@oak.highrise.ca
обсуждение исходный текст
Ответ на Re: git: uh-oh  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
* Tom Lane <tgl@sss.pgh.pa.us> [100820 16:28]:
> Uh, no, the excitement is about this:
> http://git.postgresql.org/gitweb?p=postgresql-migration.git;a=shortlog;h=refs/tags/REL8_3_10
>
> There are a whole lot of commits listed there that have nothing to do
> with anything that ever happened on the 8.3 branch.

Sure, but "gitweb" isn't doing a good job of showing you the branches &
merges.  If you use a tool that can show you the brances and merges,
what you'll see is that the the "merges" are all cases where commits
happend to all branches, and cvs2svn/cvs2git is trying to gropu them
together.

So, the real "git repository" history looks something like:


master --A___B___C__C___C__F__G__H__I___
8.4       \___a_____________\__f______

But gitweb is showing you (for 8.4) something like   f   F   E   D   C   B   a   A

If you view it in something like gitk:   gitk --date-order origin/REL8_3_STABLE origin/REL8_4_STABLE origin/master
you can see much more clearly that it's just synthisizing merge commtis to combine changes
from the 1st commited change (usually in HEAD/master) to the branches.

Take a look:
 Author: Andrew Dunstan <andrew@dunslane.net>  2010-05-13 12:39:43 Committer: Andrew Dunstan <andrew@dunslane.net>
2010-05-1312:39:43 Parent: 63c9dfe37db08b03ebbb91a96814c685a80ed257 (Assorted fixes to make pg_upgrade build on MSVC.)
Child: 4a34da914360d7d3edaa26e9a0242be74a7d90ea (Prevent PL/Tcl from loading the "unknown" module from pltcl_modules
unless)Child:  d8597e4d2896841437e9cfe12f403c83021d6f29 (This commit was manufactured by cvs2svn to create branch
'REL8_4_STABLE'.)Child:  a18a19c0b0d62e8a707755ff4b0125b67eb8f7ea (This commit was manufactured by cvs2svn to create
branch'REL8_3_STABLE'.) Branches: master, remotes/origin/REL7_4_STABLE, remotes/origin/REL8_0_STABLE,
remotes/origin/REL8_1_STABLE,remotes/origin/REL8_2_STABLE, remotes/origin/REL8_3_STABLE, remotes/origin/REL8_4_STABLE,
remotes/origin/REL9_0_STABLE,remotes/origin/foobranch, remotes/origin/master Follows: REL9_0_BETA1 Precedes: REL7_4_29,
REL8_0_25,REL8_1_21, REL8_2_17, REL8_3_11, REL8_4_4, REL9_0_BETA2 
   Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is   fundamentally insecure. Instead
applyan opmask to the whole interpreter that   imposes restrictions on unsafe operations. These restrictions are much
harder  to subvert than is Safe.pm, since there is no container to be broken out of.   Backported to release 7.4.
Inreleases 7.4, 8.0 and 8.1 this also includes the necessary backporting of   the two interpreters model for plperl and
plperluadopted in release 8.2.      In versions 8.0 and up, the use of Perl's POSIX module to undo its locale
manglingon Windows has become insecure with these changes, so it is   replaced by our own routine, which is also
faster.     Nice side effects of the changes include that it is now possible to use perl's   "strict" pragma in a
naturalway in plperl, and that perl's $a and   $b variables now work as expected in sort routines, and that function
compilationis significantly faster.      Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and   Alexey
Klyukin.     Security: CVE-2010-1169 

So, this was where Andrew committed this fix to cvs HEAD, and then immediately
afterwards to all the other branches.  But in the other branches, cvs2git
"merges" this commit it, masaghing the tree to be able todo that ;-(

In 8.4, we see: Author: PostgreSQL Daemon <webmaster@postgresql.org>  2010-05-13 12:39:49 Committer: PostgreSQL Daemon
<webmaster@postgresql.org> 2010-05-13 12:39:49 Parent: b62e4ea4823443ac6cbd01e14ccbc4010159490b (Fix some spelling
errors.)Parent: 97dfa4bccb5d7a2d5951b60b3f4e122b633126d5 (Abandon the use of Perl's Safe.pm to enforce restrictions in
plperl,as it is) Child:  851d3e0a9b9214337f96b65c39c43feae272daad (Abandon the use of Perl's Safe.pm to enforce
restrictionsin plperl, as it is) Branch: remotes/origin/REL8_4_STABLE Follows: REL8_4_2, REL9_0_BETA1 Precedes:
REL8_4_4
   This commit was manufactured by cvs2svn to create branch 'REL8_4_STABLE'.
 Author: Andrew Dunstan <andrew@dunslane.net>  2010-05-13 12:40:36 Committer: Andrew Dunstan <andrew@dunslane.net>
2010-05-1312:40:36 Parent: d8597e4d2896841437e9cfe12f403c83021d6f29 (This commit was manufactured by cvs2svn to create
branch'REL8_4_STABLE'.) Child:  3b0a36679590e6db1d93cc2c4631f910d789c286 (Prevent PL/Tcl from loading the "unknown"
modulefrom pltcl_modules unless) Branch: remotes/origin/REL8_4_STABLE Follows: REL8_4_2, REL9_0_BETA1 Precedes:
REL8_4_4   Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is   fundamentally insecure.
Insteadapply an opmask to the whole interpreter that   imposes restrictions on unsafe operations. These restrictions
aremuch harder   to subvert than is Safe.pm, since there is no container to be broken out of.   Backported to release
7.4.     In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of   the two interpreters model for
plperland plperlu adopted in release 8.2.      In versions 8.0 and up, the use of Perl's POSIX module to undo its
locale  mangling on Windows has become insecure with these changes, so it is   replaced by our own routine, which is
alsofaster.      Nice side effects of the changes include that it is now possible to use perl's   "strict" pragma in a
naturalway in plperl, and that perl's $a and   $b variables now work as expected in sort routines, and that function
compilationis significantly faster.      Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and   Alexey
Klyukin.   
In 8.3, we see: Author: PostgreSQL Daemon <webmaster@postgresql.org>  2010-05-13 12:39:48 Committer: PostgreSQL Daemon
<webmaster@postgresql.org> 2010-05-13 12:39:48 Parent: 210e6b90636a734ac43de2ff0b882497527ce489 (Fix some spelling
errors.)Parent: 97dfa4bccb5d7a2d5951b60b3f4e122b633126d5 (Abandon the use of Perl's Safe.pm to enforce restrictions in
plperl,as it is) Child:  0dc3ceaf04e89c759b46570a885eb04ca1980eef (Abandon the use of Perl's Safe.pm to enforce
restrictionsin plperl, as it is) Branch: remotes/origin/REL8_3_STABLE Follows: REL8_3_10, REL9_0_BETA1 Precedes:
REL8_3_11
   This commit was manufactured by cvs2svn to create branch 'REL8_3_STABLE'.
 Author: Andrew Dunstan <andrew@dunslane.net>  2010-05-13 12:42:51 Committer: Andrew Dunstan <andrew@dunslane.net>
2010-05-1312:42:51 Parent: a18a19c0b0d62e8a707755ff4b0125b67eb8f7ea (This commit was manufactured by cvs2svn to create
branch'REL8_3_STABLE'.) Child:  20b4301ee7bda4ff5d1d46deddd318c964ca1cc8 (Prevent PL/Tcl from loading the "unknown"
modulefrom pltcl_modules unless) Branch: remotes/origin/REL8_3_STABLE Follows: REL8_3_10, REL9_0_BETA1 Precedes:
REL8_3_11
   Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is   fundamentally insecure. Instead
applyan opmask to the whole interpreter that   imposes restrictions on unsafe operations. These restrictions are much
harder  to subvert than is Safe.pm, since there is no container to be broken out of.   Backported to release 7.4.
Inreleases 7.4, 8.0 and 8.1 this also includes the necessary backporting of   the two interpreters model for plperl and
plperluadopted in release 8.2.      In versions 8.0 and up, the use of Perl's POSIX module to undo its locale
manglingon Windows has become insecure with these changes, so it is   replaced by our own routine, which is also
faster.     Nice side effects of the changes include that it is now possible to use perl's   "strict" pragma in a
naturalway in plperl, and that perl's $a and   $b variables now work as expected in sort routines, and that function
compilationis significantly faster.      Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and   Alexey
Klyukin.     Security: CVE-2010-1169 

*but*, since it's "merged in", if you look at gitweb's history of 8.3, or 8.4,
you see the complete history of HEAD/master in as well (or, at least up to the latest
merge into the branch).  That's because gitweb is showing you a "graph" of
histroy as a single long list.

So, I'm agreeing, it's not the history that PostgreSQL wants in it's git repo,
but it is self-consistent with what cvs2svn/cvs2git is trying to do - group
non-atomic changes done with the same "commit message" and close enough
timestamps to a non-atomic CVS repository together as atomic changesets in a
atomic git repository.  And it's having to synthisize these commits to be able
to "link" the commits together.

a.

--
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: git: uh-oh
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Version Numbering