Menu
▾
▴
gnuplot-beta — Developers and beta testers of new gnuplot code
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(83) |
Nov
(57) |
Dec
(111) |
| 2004 |
Jan
(38) |
Feb
(121) |
Mar
(107) |
Apr
(241) |
May
(102) |
Jun
(190) |
Jul
(239) |
Aug
(158) |
Sep
(184) |
Oct
(193) |
Nov
(47) |
Dec
(68) |
| 2005 |
Jan
(190) |
Feb
(105) |
Mar
(99) |
Apr
(65) |
May
(92) |
Jun
(250) |
Jul
(197) |
Aug
(128) |
Sep
(101) |
Oct
(183) |
Nov
(186) |
Dec
(42) |
| 2006 |
Jan
(102) |
Feb
(122) |
Mar
(154) |
Apr
(196) |
May
(181) |
Jun
(281) |
Jul
(310) |
Aug
(198) |
Sep
(145) |
Oct
(188) |
Nov
(134) |
Dec
(90) |
| 2007 |
Jan
(134) |
Feb
(181) |
Mar
(157) |
Apr
(57) |
May
(81) |
Jun
(204) |
Jul
(60) |
Aug
(37) |
Sep
(17) |
Oct
(90) |
Nov
(122) |
Dec
(72) |
| 2008 |
Jan
(130) |
Feb
(108) |
Mar
(160) |
Apr
(38) |
May
(83) |
Jun
(42) |
Jul
(75) |
Aug
(16) |
Sep
(71) |
Oct
(57) |
Nov
(59) |
Dec
(152) |
| 2009 |
Jan
(73) |
Feb
(213) |
Mar
(67) |
Apr
(40) |
May
(46) |
Jun
(82) |
Jul
(73) |
Aug
(57) |
Sep
(108) |
Oct
(36) |
Nov
(153) |
Dec
(77) |
| 2010 |
Jan
(42) |
Feb
(171) |
Mar
(150) |
Apr
(6) |
May
(22) |
Jun
(34) |
Jul
(31) |
Aug
(38) |
Sep
(32) |
Oct
(59) |
Nov
(13) |
Dec
(62) |
| 2011 |
Jan
(114) |
Feb
(139) |
Mar
(126) |
Apr
(51) |
May
(53) |
Jun
(29) |
Jul
(41) |
Aug
(29) |
Sep
(35) |
Oct
(87) |
Nov
(42) |
Dec
(20) |
| 2012 |
Jan
(111) |
Feb
(66) |
Mar
(35) |
Apr
(59) |
May
(71) |
Jun
(32) |
Jul
(11) |
Aug
(48) |
Sep
(60) |
Oct
(87) |
Nov
(16) |
Dec
(38) |
| 2013 |
Jan
(5) |
Feb
(19) |
Mar
(41) |
Apr
(47) |
May
(14) |
Jun
(32) |
Jul
(18) |
Aug
(68) |
Sep
(9) |
Oct
(42) |
Nov
(12) |
Dec
(10) |
| 2014 |
Jan
(14) |
Feb
(139) |
Mar
(137) |
Apr
(66) |
May
(72) |
Jun
(142) |
Jul
(70) |
Aug
(31) |
Sep
(39) |
Oct
(98) |
Nov
(133) |
Dec
(44) |
| 2015 |
Jan
(70) |
Feb
(27) |
Mar
(36) |
Apr
(11) |
May
(15) |
Jun
(70) |
Jul
(30) |
Aug
(63) |
Sep
(18) |
Oct
(15) |
Nov
(42) |
Dec
(29) |
| 2016 |
Jan
(37) |
Feb
(48) |
Mar
(59) |
Apr
(28) |
May
(30) |
Jun
(43) |
Jul
(47) |
Aug
(14) |
Sep
(21) |
Oct
(26) |
Nov
(10) |
Dec
(2) |
| 2017 |
Jan
(26) |
Feb
(27) |
Mar
(44) |
Apr
(11) |
May
(32) |
Jun
(28) |
Jul
(75) |
Aug
(45) |
Sep
(35) |
Oct
(285) |
Nov
(99) |
Dec
(16) |
| 2018 |
Jan
(8) |
Feb
(8) |
Mar
(42) |
Apr
(35) |
May
(23) |
Jun
(12) |
Jul
(16) |
Aug
(11) |
Sep
(8) |
Oct
(16) |
Nov
(5) |
Dec
(8) |
| 2019 |
Jan
(9) |
Feb
(28) |
Mar
(4) |
Apr
(10) |
May
(7) |
Jun
(4) |
Jul
(4) |
Aug
|
Sep
(4) |
Oct
|
Nov
(23) |
Dec
(3) |
| 2020 |
Jan
(19) |
Feb
(3) |
Mar
(22) |
Apr
(17) |
May
(10) |
Jun
(69) |
Jul
(18) |
Aug
(23) |
Sep
(25) |
Oct
(11) |
Nov
(20) |
Dec
(9) |
| 2021 |
Jan
(1) |
Feb
(7) |
Mar
(9) |
Apr
|
May
(1) |
Jun
(8) |
Jul
(6) |
Aug
(8) |
Sep
(7) |
Oct
|
Nov
(2) |
Dec
(23) |
| 2022 |
Jan
(23) |
Feb
(9) |
Mar
(9) |
Apr
|
May
(8) |
Jun
(1) |
Jul
(6) |
Aug
(8) |
Sep
(30) |
Oct
(5) |
Nov
(4) |
Dec
(6) |
| 2023 |
Jan
(2) |
Feb
(5) |
Mar
(7) |
Apr
(3) |
May
(8) |
Jun
(45) |
Jul
(8) |
Aug
|
Sep
(2) |
Oct
(14) |
Nov
(7) |
Dec
(2) |
| 2024 |
Jan
(4) |
Feb
(4) |
Mar
|
Apr
(7) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
(4) |
Dec
(14) |
| 2025 |
Jan
(22) |
Feb
(6) |
Mar
(5) |
Apr
(14) |
May
(6) |
Jun
(11) |
Jul
(19) |
Aug
|
Sep
(17) |
Oct
(1) |
Nov
(2) |
Dec
(18) |
| 2026 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(2) |
Jun
(1) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Eric S. R. <es...@th...> - 2017-10-18 23:54:49
|
Ethan A Merritt <sf...@us...>: > Except one - > "Release_4_6_3" should have been renamed to 4.6.3 in your previous > mass-renaming. It must have been missed. Got it. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. |
|
From: Daniel J S. <dan...@ie...> - 2017-10-18 23:48:22
|
On 10/18/2017 06:09 PM, Eric S. Raymond wrote: > I'm going to start tagging the conversions by the SHA1 of the head > commit. This should change every time the repo content does. > > Don't trust the branch and tag display in the SourceForge GUI. It > doesn't always update properly when I push a new conversion. Clone > and do git tag -l and git branch to see the true state of affairs. > > This version was pushed with --mirror, so Daniel should see all > the branches. I see them! :-) There are a whole bunch of extra branches in there (see below), e.g., BETA_340 GNUPLOT_3_7_0_2 etc. But certainly the branch-4-0-stable, etc. branches are present. Ethan, you should be able to perform "get checkout branch-5-2-stable" now. I don't know much historical about the release schedule and branches, so take a look at "git branch -l -r" (or gitg). Do these make sense to you? Dan sebald@ ~/gnuplot/test_repository/third_sourceforge/git-main $ git branch -l -r origin/BETA_340 origin/BETA_343 origin/BETA_343_980412 [snip] origin/BETA_349_990112 origin/BETA_349_99011201 origin/BETA_349_990113 origin/GNUPLOT_19991029 origin/GNUPLOT_19991103 origin/GNUPLOT_19991108 [snip] origin/GNUPLOT_991021 origin/GNUPLOT_RELEASE_3_7_0 origin/GNUPLOT_RELEASE_4_0_0 origin/GNUPLOT_RELEASE_4_0_1 origin/GNUPLOT_RELEASE_4_0_2 origin/GNUPOT_20000211 origin/HEAD -> origin/master origin/MAIN-pre-3-8d origin/Release_4_6_3 origin/axis_branch_base origin/branch-4-0-stable origin/branch-4-2-stable origin/branch-4-4-stable origin/branch-4-6-stable origin/branch-5-0-stable origin/branch-5-2-stable origin/branch-pre-3-7-1 origin/column origin/gnuplot-3-8d origin/gnuplot-3-8e origin/gnuplot-3-8g origin/gnuplot-3-8i origin/gnuplot-3-8j origin/gnuplot-3-8k origin/gnuplot-3-8k-1 origin/gnuplot-3-8k-2 origin/gnuplot-3-8k-3 origin/import-1.1.1 origin/lhecking_20001103 origin/master origin/pm3d origin/pre-column-01 [snip] origin/pre-pm3d-07 origin/pre-pm3d-08 origin/pre-pm3d-09 origin/pre-pm3d-10 origin/pre-relative-arrows |
|
From: Ethan A M. <sf...@us...> - 2017-10-18 23:48:12
|
On Wednesday, October 18, 2017 4:30:34 PM PDT Eric S. Raymond wrote: > Ethan A Merritt <sf...@us...>: > > > This version does not delete any of the junk tags or branches. > > > Should the following tags be kept? > > > > I think not. > > Excellent, that leaves the tag list looking very clean. It just has > the release tags and the 'git-conversion; annotated tag on it now. > > Next question is, shall I nuke the tags that don't refer to a gitspace > revision? Checking these out probably won't reflect what was intended, > due to missing CVS tags in some masters that should have them. Those all predate my involvement, so I don't know what historical benchmarks they correspond to. Lars - is there a reason to keep those almost-daily tags from 1998/1999? Except one - "Release_4_6_3" should have been renamed to 4.6.3 in your previous mass-renaming. It must have been missed. Ethan > > BETA_340 > BETA_343 > BETA_343_980412 > BETA_343_980413 > BETA_343_980415 > BETA_343_980416 > BETA_344 > BETA_344_980507 > BETA_344_980508 > BETA_344_980512 > BETA_344_989422 > BETA_345 > BETA_345_980617 > BETA_345_980619 > BETA_345_980622 > BETA_346 > BETA_347 > BETA_347_980708 > BETA_347_980715 > BETA_347_980818 > BETA_347_980819 > BETA_347_980824 > BETA_347_980831 > BETA_347_980916 > BETA_347_98091601 > BETA_347_980918 > BETA_347_980921 > BETA_347_980922 > BETA_347_980923 > BETA_347_981001 > BETA_347_981003 > BETA_347_981009 > BETA_347_981012 > BETA_347_981013 > BETA_347_981016 > BETA_347_981019 > BETA_347_98101901 > BETA_347_981020 > BETA_347_981028 > BETA_347_981103 > BETA_347_981104 > BETA_347_98110401 > BETA_347_981106 > BETA_347_981112 > BETA_347_981116 > BETA_347_981117 > BETA_347_981119 > BETA_347_981120 > BETA_347_98112001 > BETA_347_981123 > BETA_347_981125 > BETA_347_981126 > BETA_347_981130 > BETA_347_981201 > BETA_347_981202 > BETA_347_pl3 > BETA_347_pl4 > BETA_347_pl5 > BETA_347_pl7 > BETA_348_981203 > BETA_348_981206 > BETA_348_981207 > BETA_348_981209 > BETA_348_981210 > BETA_348_981214 > BETA_348_release > BETA_349_981215 > BETA_349_981216 > BETA_349_981217 > BETA_349_981221 > BETA_349_981222 > BETA_349_981223 > BETA_349_990106 > BETA_349_990112 > BETA_349_99011201 > BETA_349_990113 > GNUPLOT_19991029 > GNUPLOT_19991103 > GNUPLOT_19991108 > GNUPLOT_19991115 > GNUPLOT_19991124 > GNUPLOT_19991201 > GNUPLOT_20000122 > GNUPLOT_20000329 > GNUPLOT_3_7_0_2 > GNUPLOT_3_7_0_3 > GNUPLOT_3_7_0_5 > GNUPLOT_3_7_0_6 > GNUPLOT_3_7_0_7 > GNUPLOT_3_7_0_8 > GNUPLOT_3_7_0_9 > GNUPLOT_3_8_a > GNUPLOT_3_8_b > GNUPLOT_3_8_c > gnuplot-3-8d > gnuplot-3-8e > gnuplot-3-8g > gnuplot-3-8i > gnuplot-3-8j > gnuplot-3-8k > gnuplot-3-8k-1 > gnuplot-3-8k-2 > gnuplot-3-8k-3 > GNUPLOT_990126 > GNUPLOT_990128 > GNUPLOT_990129 > GNUPLOT_990201 > GNUPLOT_990204 > GNUPLOT_990210 > GNUPLOT_990214 > GNUPLOT_990217 > GNUPLOT_990222 > GNUPLOT_990223 > GNUPLOT_990225 > GNUPLOT_990301 > GNUPLOT_990304 > GNUPLOT_990310 > GNUPLOT_990317 > GNUPLOT_990319 > GNUPLOT_990323 > GNUPLOT_990326 > GNUPLOT_990326_TRANSITIONAL > GNUPLOT_990327_TRANSITIONAL_1 > GNUPLOT_990328_TRANSITIONAL_1 > GNUPLOT_990330 > GNUPLOT_990331 > GNUPLOT_990403 > GNUPLOT_990405 > GNUPLOT_990416 > GNUPLOT_990422 > GNUPLOT_990427 > GNUPLOT_990504 > GNUPLOT_990512 > GNUPLOT_990513 > GNUPLOT_990514 > GNUPLOT_990519 > GNUPLOT_990520 > GNUPLOT_990527 > GNUPLOT_990530 > GNUPLOT_990531 > GNUPLOT_990606 > GNUPLOT_990609 > GNUPLOT_990610 > GNUPLOT_990611 > GNUPLOT_99061101 > GNUPLOT_990614 > GNUPLOT_990617 > GNUPLOT_990619 > GNUPLOT_990622 > GNUPLOT_990625 > GNUPLOT_990630 > GNUPLOT_990709 > GNUPLOT_990713 > GNUPLOT_990718 > GNUPLOT_990720 > GNUPLOT_990727 > GNUPLOT_990730 > GNUPLOT_990807 > GNUPLOT_990808 > GNUPLOT_990809 > GNUPLOT_990811 > GNUPLOT_990817 > GNUPLOT_990820 > GNUPLOT_990824 > GNUPLOT_990914 > GNUPLOT_990921 > GNUPLOT_990924 > GNUPLOT_991001 > GNUPLOT_991017 > GNUPLOT_991021 > GNUPLOT_RELEASE_3_7_0 > GNUPLOT_RELEASE_4_0_0 > GNUPLOT_RELEASE_4_0_1 > GNUPLOT_RELEASE_4_0_2 > GNUPOT_20000211 > lhecking_20001103 > MAIN-pre-3-8d > pre-column-01 > pre-column-02 > pre-column-03 > pre-column-04 > pre-column-05 > pre-column-06 > pre-column-07 > pre-column-MAIN-1 > pre-column-MAIN-2 > pre-pm3d > pre-pm3d-01 > pre-pm3d-02a > pre-pm3d-03 > pre-pm3d-04 > pre-pm3d-05 > pre-pm3d-06 > pre-pm3d-07 > pre-pm3d-08 > pre-pm3d-09 > pre-pm3d-10 > pre-relative-arrows > Release_4_6_3 |
|
From: Daniel J S. <dan...@ie...> - 2017-10-18 23:32:23
|
On 10/18/2017 06:16 PM, Eric S. Raymond wrote: > Daniel J Sebald <dan...@ie...>: >> On 10/18/2017 03:25 PM, "Bastian Märkisch" wrote: >>> Thank you for the new version. Overall the attribution algorithm >>> seems to work remarkably well! There are a number of cases though >>> were it fails. >>> >>> Here's an example (picked more or less randomly): >>> https://sourceforge.net/p/gnuplot/git-main/ci/26f769db9e954052b11dbc8f242fc35a3cfd6880/ >>> This one is attributed to Ethan, although the change is by me. >>> The reason seems to be that the Changelog entry is inserted below >>> an entry by Ethan on the same day. I think that is not an uncommon >>> case, in fact I quickly found around a dozen such cases. Can this >>> be taken into account or do we have to check manually? >> >> This why in the algorithm I wrote the search is backward from the first >> change in ChangeLog. >> >> Dan > > I don't know what you mean by "backward". "First" is topmost? The utility is searching a file, so think of searching a diff hunk from the start of the file (text). One of Peter's examples (redacted email addresses) below. After the line "+++", look forward until finding the first line with a '+' in the first column. Now, from that line search backward and we find Bastian as author, not Peter. Peter is the first author in the modified file, but that isn't correct for this changeset: sebald@ ~/gnuplot/test_repository/second_sourceforge/git-main $ git diff 6b9ff30e7754e7fb07ac4f05d38a558b93ba7102 63bc0f364a43d74ceca514a1954e2efa6c4ad7f6 --unified=10 ChangeLog diff --git a/ChangeLog b/ChangeLog index 4681d7f..35c39d8 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,17 +1,22 @@ 2011-11-14 Peter Jjjjjj <xxxxxx@xxxxxx> * src/plot2d.c (store2d_point): Fix for 4-column mode of BOXPLOT style which did not handle log scale correctly. 2011-11-14 Bastian Mmmmmm <xxxxxx@xxxxxx> + src/win.trm (WIN_set_color): Immediately translate palette color + values to RGB instead of passing them on. This makes it possible + to use more than one palettes in multiplots and in different + graph windows. Test e.g. with pm3dcolors.dem + * src/win/wgraph.c src/win/wresourc.h src/win/wgnuplib.h: Add a separate switch to toggle antialiasing of polygons. * src/win/wgraph.c (Draw_XOR_Text): Implement a 10 year old FIXME: Use proper raster operation instead of double inversion. 2011-11-12 Ssssss Tttttt <xxxxxx@xxxxxx> * src/win/README.win-ja src/win/wgnuplot-ja.mnu: Update and sync with wgnuplot.mnu Dan |
|
From: Eric S. R. <es...@th...> - 2017-10-18 23:30:43
|
Ethan A Merritt <sf...@us...>: > > This version does not delete any of the junk tags or branches. > > Should the following tags be kept? > > I think not. Excellent, that leaves the tag list looking very clean. It just has the release tags and the 'git-conversion; annotated tag on it now. Next question is, shall I nuke the tags that don't refer to a gitspace revision? Checking these out probably won't reflect what was intended, due to missing CVS tags in some masters that should have them. BETA_340 BETA_343 BETA_343_980412 BETA_343_980413 BETA_343_980415 BETA_343_980416 BETA_344 BETA_344_980507 BETA_344_980508 BETA_344_980512 BETA_344_989422 BETA_345 BETA_345_980617 BETA_345_980619 BETA_345_980622 BETA_346 BETA_347 BETA_347_980708 BETA_347_980715 BETA_347_980818 BETA_347_980819 BETA_347_980824 BETA_347_980831 BETA_347_980916 BETA_347_98091601 BETA_347_980918 BETA_347_980921 BETA_347_980922 BETA_347_980923 BETA_347_981001 BETA_347_981003 BETA_347_981009 BETA_347_981012 BETA_347_981013 BETA_347_981016 BETA_347_981019 BETA_347_98101901 BETA_347_981020 BETA_347_981028 BETA_347_981103 BETA_347_981104 BETA_347_98110401 BETA_347_981106 BETA_347_981112 BETA_347_981116 BETA_347_981117 BETA_347_981119 BETA_347_981120 BETA_347_98112001 BETA_347_981123 BETA_347_981125 BETA_347_981126 BETA_347_981130 BETA_347_981201 BETA_347_981202 BETA_347_pl3 BETA_347_pl4 BETA_347_pl5 BETA_347_pl7 BETA_348_981203 BETA_348_981206 BETA_348_981207 BETA_348_981209 BETA_348_981210 BETA_348_981214 BETA_348_release BETA_349_981215 BETA_349_981216 BETA_349_981217 BETA_349_981221 BETA_349_981222 BETA_349_981223 BETA_349_990106 BETA_349_990112 BETA_349_99011201 BETA_349_990113 GNUPLOT_19991029 GNUPLOT_19991103 GNUPLOT_19991108 GNUPLOT_19991115 GNUPLOT_19991124 GNUPLOT_19991201 GNUPLOT_20000122 GNUPLOT_20000329 GNUPLOT_3_7_0_2 GNUPLOT_3_7_0_3 GNUPLOT_3_7_0_5 GNUPLOT_3_7_0_6 GNUPLOT_3_7_0_7 GNUPLOT_3_7_0_8 GNUPLOT_3_7_0_9 GNUPLOT_3_8_a GNUPLOT_3_8_b GNUPLOT_3_8_c gnuplot-3-8d gnuplot-3-8e gnuplot-3-8g gnuplot-3-8i gnuplot-3-8j gnuplot-3-8k gnuplot-3-8k-1 gnuplot-3-8k-2 gnuplot-3-8k-3 GNUPLOT_990126 GNUPLOT_990128 GNUPLOT_990129 GNUPLOT_990201 GNUPLOT_990204 GNUPLOT_990210 GNUPLOT_990214 GNUPLOT_990217 GNUPLOT_990222 GNUPLOT_990223 GNUPLOT_990225 GNUPLOT_990301 GNUPLOT_990304 GNUPLOT_990310 GNUPLOT_990317 GNUPLOT_990319 GNUPLOT_990323 GNUPLOT_990326 GNUPLOT_990326_TRANSITIONAL GNUPLOT_990327_TRANSITIONAL_1 GNUPLOT_990328_TRANSITIONAL_1 GNUPLOT_990330 GNUPLOT_990331 GNUPLOT_990403 GNUPLOT_990405 GNUPLOT_990416 GNUPLOT_990422 GNUPLOT_990427 GNUPLOT_990504 GNUPLOT_990512 GNUPLOT_990513 GNUPLOT_990514 GNUPLOT_990519 GNUPLOT_990520 GNUPLOT_990527 GNUPLOT_990530 GNUPLOT_990531 GNUPLOT_990606 GNUPLOT_990609 GNUPLOT_990610 GNUPLOT_990611 GNUPLOT_99061101 GNUPLOT_990614 GNUPLOT_990617 GNUPLOT_990619 GNUPLOT_990622 GNUPLOT_990625 GNUPLOT_990630 GNUPLOT_990709 GNUPLOT_990713 GNUPLOT_990718 GNUPLOT_990720 GNUPLOT_990727 GNUPLOT_990730 GNUPLOT_990807 GNUPLOT_990808 GNUPLOT_990809 GNUPLOT_990811 GNUPLOT_990817 GNUPLOT_990820 GNUPLOT_990824 GNUPLOT_990914 GNUPLOT_990921 GNUPLOT_990924 GNUPLOT_991001 GNUPLOT_991017 GNUPLOT_991021 GNUPLOT_RELEASE_3_7_0 GNUPLOT_RELEASE_4_0_0 GNUPLOT_RELEASE_4_0_1 GNUPLOT_RELEASE_4_0_2 GNUPOT_20000211 lhecking_20001103 MAIN-pre-3-8d pre-column-01 pre-column-02 pre-column-03 pre-column-04 pre-column-05 pre-column-06 pre-column-07 pre-column-MAIN-1 pre-column-MAIN-2 pre-pm3d pre-pm3d-01 pre-pm3d-02a pre-pm3d-03 pre-pm3d-04 pre-pm3d-05 pre-pm3d-06 pre-pm3d-07 pre-pm3d-08 pre-pm3d-09 pre-pm3d-10 pre-relative-arrows Release_4_6_3 -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. |
|
From: Eric S. R. <es...@th...> - 2017-10-18 23:22:21
|
Daniel J Sebald <dan...@ie...>: > >I've also scanned through the commits attributed to me in the new git > >repo, and I strongly suspect that some of those were not done by me. > >E.g. 63bc0f364a43d74ceca514a1954e2efa6c4ad7f6, > > This one, by search-backward-from-first-change rule, would go to > > 2011-11-14 Bastian M <xxxxxx@xxxxxx> Ahhhh, *now* I think I understand. Instead of the topmost entry you're looking for the first entry prevuius to the first changed line. I think I can do that. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. |
|
From: Daniel J S. <dan...@ie...> - 2017-10-18 23:20:09
|
On 10/18/2017 06:09 PM, Daniel J Sebald wrote: > On 10/18/2017 05:10 PM, Eric S. Raymond wrote: >> "Bastian Märkisch" <bma...@we...>: [snip] > See the code associated with the utility here: > > https://sourceforge.net/p/gnuplot/patches/_discuss/thread/e85f41d6/97ca/attachment/git_changelog_author.cc Actual 0.3 beta is the most recent: https://sourceforge.net/p/gnuplot/patches/_discuss/thread/e85f41d6/db35/attachment/git_changelog_author.cc one small difference between the two, i.e., break out of search loop if author information is a subtraction rather than continue the search loop. Dan |
|
From: Eric S. R. <es...@th...> - 2017-10-18 23:17:05
|
Daniel J Sebald <dan...@ie...>: > On 10/18/2017 03:25 PM, "Bastian Märkisch" wrote: > >Thank you for the new version. Overall the attribution algorithm > >seems to work remarkably well! There are a number of cases though > >were it fails. > > > >Here's an example (picked more or less randomly): > >https://sourceforge.net/p/gnuplot/git-main/ci/26f769db9e954052b11dbc8f242fc35a3cfd6880/ > >This one is attributed to Ethan, although the change is by me. > >The reason seems to be that the Changelog entry is inserted below > >an entry by Ethan on the same day. I think that is not an uncommon > >case, in fact I quickly found around a dozen such cases. Can this > >be taken into account or do we have to check manually? > > This why in the algorithm I wrote the search is backward from the first > change in ChangeLog. > > Dan I don't know what you mean by "backward". "First" is topmost? -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. |
|
From: Ethan A M. <sf...@us...> - 2017-10-18 23:16:13
|
On Wednesday, October 18, 2017 4:09:31 PM PDT Eric S. Raymond wrote: > I'm going to start tagging the conversions by the SHA1 of the head > commit. This should change every time the repo content does. > > Don't trust the branch and tag display in the SourceForge GUI. It > doesn't always update properly when I push a new conversion. Clone > and do git tag -l and git branch to see the true state of affairs. > > This version was pushed with --mirror, so Daniel should see all > the branches. > > I've renamed all the release tags to a uniform x.y.z format. OK > This version does not delete any of the junk tags or branches. > Should the following tags be kept? I think not. Ethan > > BETA_347_980925 > BETA_347_981005 > BETA_347_98101301 > BETA_347_981121 > BETA_348 > BETA_348_981204 > BETA_349 > BETA_349_990114 > GNUPLOT_19991210 > GNUPLOT_20000330 > GNUPLOT_37_20000507 > GNUPLOT_990311 > GNUPLOT_990312 > GNUPLOT_990404 > GNUPLOT_990507 > GNUPLOT_990602 > GNUPLOT_990612 > GNUPLOT_990705 > GNUPLOT_RELEASE_19991103 > Release_4_2_1-pre1 > Release_4_4_rc1 > Release_4_6_rc1 > axis-checkpoint-sourceforge-20000728 > gnuplot-3-8f > gnuplot-4-4-alpha > gnuplot-4-6-alpha > gnuplot-5-0-rc2 > gnuplot-5-2-rc0 > pm3d-14 > pre-lt-palette > pre-macport > pre-pm3d-02 > pre-pm3d-11 |
|
From: Daniel J S. <dan...@ie...> - 2017-10-18 23:10:12
|
On 10/18/2017 05:10 PM, Eric S. Raymond wrote: > "Bastian Märkisch" <bma...@we...>: >> Thank you for the new version. Overall the attribution algorithm >> seems to work remarkably well! There are a number of cases though >> were it fails. >> >> Here's an example (picked more or less randomly): >> https://sourceforge.net/p/gnuplot/git-main/ci/26f769db9e954052b11dbc8f242fc35a3cfd6880/ >> This one is attributed to Ethan, although the change is by me. >> The reason seems to be that the Changelog entry is inserted below >> an entry by Ethan on the same day. I think that is not an uncommon >> case, in fact I quickly found around a dozen such cases. Can this >> be taken into account or do we have to check manually? > > Inserting an entry *below* the previous one defeats my naive algorithm, which > simply assumed that the topmost entry in the ChangeLog is the most recent and > most relevant one. > > I'm open to suggestions about a better algorithm, but...if it's not to assume > that the topmost entry is the right one, what rule should be used? Under > what circumstances do attributions get inserted below that? > > You may have to fix these manually. See the code associated with the utility here: https://sourceforge.net/p/gnuplot/patches/_discuss/thread/e85f41d6/97ca/attachment/git_changelog_author.cc Basically, 1) Find first change in changelog 2) Search backward to find the author info 3) Heuristics: a) Author info can't be a *subtraction*, i.e., a '-' in first column (that indicates wholesale swap of ChangeLog file or corrected author info) b) If it is only the ChangeLog that was modified, do nothing (that indicates the committer simply modified like a date or typo in the ChangeLog, i.e., the scenario Peter described) The above may not be exactly what the code is doing, but it is close, with nuance. The search requires, of course, that backward from the first change there is going to be adequate author information. I.e., that the ChangeLog message isn't going to be so long that the author info is dropped. That is why I used git log --format='commit <%cE!%cIZ>' -p --unified=50 ChangeLog > CL.diff That is, give me 50 lines prior to the first diff hunk, with the assumption that no one has written a ChangeLog message 50 lines long. >> Another idea concerning the CVS conversion: at the early stages of >> the gnuplot CVS repo, files were moved from the top directory to >> sub-directories. That is they were deleted and added to CVS again. >> Hence the history before the move is kind of lost. While not super >> important, I wonder if this could be easily ammended now? > > Can you be more specific about the time this happened, and in what way the > git conversion fails to reflect the old history? > > The way cvs-fast-export works *may* already solve this problem. It scans > masters in the attic directory - it has to, because that's where deleted > files go. In fact attic files are treated pretty much as though they were > at their original, pre-attic locations, so if a commit clique is found by > matching time and comment it does not matter that some of the file > revisions are in the attic and some are not. Most VCS's didn't "move" files, up until git, et al. And I'm not exactly sure even git technically has an action "move". Dan |
|
From: <es...@th...> - 2017-10-18 23:09:39
|
I'm going to start tagging the conversions by the SHA1 of the head commit. This should change every time the repo content does. Don't trust the branch and tag display in the SourceForge GUI. It doesn't always update properly when I push a new conversion. Clone and do git tag -l and git branch to see the true state of affairs. This version was pushed with --mirror, so Daniel should see all the branches. I've renamed all the release tags to a uniform x.y.z format. This version does not delete any of the junk tags or branches. Should the following tags be kept? BETA_347_980925 BETA_347_981005 BETA_347_98101301 BETA_347_981121 BETA_348 BETA_348_981204 BETA_349 BETA_349_990114 GNUPLOT_19991210 GNUPLOT_20000330 GNUPLOT_37_20000507 GNUPLOT_990311 GNUPLOT_990312 GNUPLOT_990404 GNUPLOT_990507 GNUPLOT_990602 GNUPLOT_990612 GNUPLOT_990705 GNUPLOT_RELEASE_19991103 Release_4_2_1-pre1 Release_4_4_rc1 Release_4_6_rc1 axis-checkpoint-sourceforge-20000728 gnuplot-3-8f gnuplot-4-4-alpha gnuplot-4-6-alpha gnuplot-5-0-rc2 gnuplot-5-2-rc0 pm3d-14 pre-lt-palette pre-macport pre-pm3d-02 pre-pm3d-11 -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln |
|
From: Daniel J S. <dan...@ie...> - 2017-10-18 22:56:49
|
On 10/18/2017 05:08 PM, Juhász Péter wrote: > On Wed, 2017-10-18 at 13:58 -0400, Eric S. Raymond wrote: >> I've pushed a version including the 1.1 release in its tail, and all >> previously missing tags should now be visible. >> >> There are somewhere around 275 commits with empty comment fields. >> These should either have comments filled in or, if they are ChanegLog >> singletons that need to be glued to another clique, I need to know >> that. >> >> I've enclosed a file named EMPTY which is in the right format to be >> read back in by reposurgeon. All of you, please fill in any comments >> you can in the commits you're responsible for; if you want to clue me >> in to a ChangeLog commit that should be squashed with the previous >> one, put SQUASH in the comment field. Don't alter the divider lines. >> >> > > I've found a single instance of my name in the file, which incidentally > points to an edge case: I had modified the Changelog file itself > (fixing the date of the entry). Perhaps this warrants a SQUASH. Those are the tricky ones I noted previously: editing some date or something. My rule was that if only the ChangeLog changes, then the authorship would not be modified. It would remain as the committer. > I've also scanned through the commits attributed to me in the new git > repo, and I strongly suspect that some of those were not done by me. > E.g. 63bc0f364a43d74ceca514a1954e2efa6c4ad7f6, This one, by search-backward-from-first-change rule, would go to 2011-11-14 Bastian M <xxxxxx@xxxxxx> > dc3d0aa052b1af8563624f46516f27def76fdb80, and Same here, first change, searching backward points to 2011-11-14 Bastian M <xxxxxx@xxxxxx> > f2093b012b3b58842ae825439bfeec85b01fa8c3 Once again, searching backward from first change points to 2011-11-14 Bastian M <xxxxxx@xxxxxx> Dan are attributed to me but they > were obviously committed by Bastian Maerkisch. (So I confirm his > finding here). The reason indeed seems to be that unrelated changes by > the same author, on the same day were squashed in the Changelog, and > change-groups belonging to different authors, on the same day are > listed in arbitrary order, even though this confuses the actual order > of the changes. > > best regards, > Peter Juhasz |
|
From: Daniel J S. <dan...@ie...> - 2017-10-18 22:46:01
|
On 10/18/2017 03:25 PM, "Bastian Märkisch" wrote: > Thank you for the new version. Overall the attribution algorithm > seems to work remarkably well! There are a number of cases though > were it fails. > > Here's an example (picked more or less randomly): > https://sourceforge.net/p/gnuplot/git-main/ci/26f769db9e954052b11dbc8f242fc35a3cfd6880/ > This one is attributed to Ethan, although the change is by me. > The reason seems to be that the Changelog entry is inserted below > an entry by Ethan on the same day. I think that is not an uncommon > case, in fact I quickly found around a dozen such cases. Can this > be taken into account or do we have to check manually? This why in the algorithm I wrote the search is backward from the first change in ChangeLog. Dan |
|
From: Daniel J S. <dan...@ie...> - 2017-10-18 22:44:27
|
On 10/18/2017 04:41 PM, Lars Hecking via gnuplot-beta wrote:
>
>> I've enclosed a file named EMPTY which is in the right format to be
>> read back in by reposurgeon. All of you, please fill in any comments
>> you can in the commits you're responsible for; if you want to clue me
>> in to a ChangeLog commit that should be squashed with the previous
>> one, put SQUASH in the comment field. Don't alter the divider lines.
>
> The ones attributed to me: not a chance. If they're not in the ChangeLog
> files, and they aren't, I certainly can't remember. Some of this is nearly
> 20 years ago.
But one can see the color-coded diff hunks very conveniently in a viewer
like gitg (or gitk). Change to the directory where the git repository
is and type "gitg" (or "gitk") and in the search window type "empty log
message". Use up-arrow or down-arrow to navigate.
Most of these "empty log message" entries are short, of the variety:
~~~
sebald@ ~/gnuplot/test_repository/second_sourceforge/git-main $ git diff
e3399d54bc75eada863922a165e2246b9e52a296
dd87121fcc81afcf07e84c7d2b02ade6f9b6619f
diff --git a/docs/gnuplot.doc b/docs/gnuplot.doc
index 09a6728..ab3c60b 100644
--- a/docs/gnuplot.doc
+++ b/docs/gnuplot.doc
@@ -1,4 +1,4 @@
-C RCS $Id: gnuplot.doc,v 1.1107 2017/09/05 20:18:58 sfeam Exp $
+C RCS $Id: gnuplot.doc,v 1.1108 2017/09/11 20:13:24 sfeam Exp $
C
C Copyright (C) 1986 - 1993, 1998, 1999, 2000, 2001, 2004 Thomas
Williams, Colin Kelley et al.
C
@@ -199,6 +199,11 @@ C
Version 5.3 is the current development version. New features
introduced here
will generally not appear in a supported release until version 5.4.
Details
may change before that.
+
+#start
+#bcreation of csv files using `set table separator {tab|comma|"char"}`
+##See `plot with table`.
+#end
3 Features introduced in version 5.2
?Features introduced in version 5.2
4 New plot styles and style options
@@ -13013,6 +13018,7 @@ Ffigure_multiple_keys
plot <file> using ("File 1"):1:2:3 with table
plot <file> using (sprintf("%4.2f",$1)) : (sprintf("%4.2f",$3))
with table
+=csv
To create a csv file use
set table "tab.csv" separator comma
plot <foo> using 1:2:3:4 with table
~~~
For which almost anyone could write a short description to replace "***
empty log message ***". My thought was that we do
git log --format='<%cE!%cIZ> %s' | grep " empty log message " >
message_map.txt
and then pass the message_map.txt file along to a half dozen people who
each fill in forty or fifty entries. The GUI makes it easy, whereas I
wouldn't want to peruse the diffs from the command line; too time consuming.
Dan
|
|
From: Eric S. R. <es...@th...> - 2017-10-18 22:24:33
|
Juhász Péter <pet...@gm...>: > I've found a single instance of my name in the file, which incidentally > points to an edge case: I had modified the Changelog file itself > (fixing the date of the entry). Perhaps this warrants a SQUASH. Thanks, comment added. > I've also scanned through the commits attributed to me in the new git > repo, and I strongly suspect that some of those were not done by me. > E.g. 63bc0f364a43d74ceca514a1954e2efa6c4ad7f6, > dc3d0aa052b1af8563624f46516f27def76fdb80, and > f2093b012b3b58842ae825439bfeec85b01fa8c3 are attributed to me but they > were obviously committed by Bastian Maerkisch. (So I confirm his > finding here). The reason indeed seems to be that unrelated changes by > the same author, on the same day were squashed in the Changelog, and > change-groups belonging to different authors, on the same day are > listed in arbitrary order, even though this confuses the actual order > of the changes. Sigh. There's nothing algorithmic I can do about that. You guys will hae to find the exception commits by hand and tell me how to re-attribute them. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. |
|
From: Eric S. R. <es...@th...> - 2017-10-18 22:11:07
|
"Bastian Märkisch" <bma...@we...>: > Thank you for the new version. Overall the attribution algorithm > seems to work remarkably well! There are a number of cases though > were it fails. > > Here's an example (picked more or less randomly): > https://sourceforge.net/p/gnuplot/git-main/ci/26f769db9e954052b11dbc8f242fc35a3cfd6880/ > This one is attributed to Ethan, although the change is by me. > The reason seems to be that the Changelog entry is inserted below > an entry by Ethan on the same day. I think that is not an uncommon > case, in fact I quickly found around a dozen such cases. Can this > be taken into account or do we have to check manually? Inserting an entry *below* the previous one defeats my naive algorithm, which simply assumed that the topmost entry in the ChangeLog is the most recent and most relevant one. I'm open to suggestions about a better algorithm, but...if it's not to assume that the topmost entry is the right one, what rule should be used? Under what circumstances do attributions get inserted below that? You may have to fix these manually. > Another idea concerning the CVS conversion: at the early stages of > the gnuplot CVS repo, files were moved from the top directory to > sub-directories. That is they were deleted and added to CVS again. > Hence the history before the move is kind of lost. While not super > important, I wonder if this could be easily ammended now? Can you be more specific about the time this happened, and in what way the git conversion fails to reflect the old history? The way cvs-fast-export works *may* already solve this problem. It scans masters in the attic directory - it has to, because that's where deleted files go. In fact attic files are treated pretty much as though they were at their original, pre-attic locations, so if a commit clique is found by matching time and comment it does not matter that some of the file revisions are in the attic and some are not. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. |
|
From: Lars H. <lhe...@us...> - 2017-10-18 22:08:38
|
> I've enclosed a file named EMPTY which is in the right format to be > read back in by reposurgeon. All of you, please fill in any comments > you can in the commits you're responsible for; if you want to clue me > in to a ChangeLog commit that should be squashed with the previous > one, put SQUASH in the comment field. Don't alter the divider lines. The ones attributed to me: not a chance. If they're not in the ChangeLog files, and they aren't, I certainly can't remember. Some of this is nearly 20 years ago. |
|
From: Juhász P. <pet...@gm...> - 2017-10-18 22:08:20
|
On Wed, 2017-10-18 at 13:58 -0400, Eric S. Raymond wrote: > I've pushed a version including the 1.1 release in its tail, and all > previously missing tags should now be visible. > > There are somewhere around 275 commits with empty comment fields. > These should either have comments filled in or, if they are ChanegLog > singletons that need to be glued to another clique, I need to know > that. > > I've enclosed a file named EMPTY which is in the right format to be > read back in by reposurgeon. All of you, please fill in any comments > you can in the commits you're responsible for; if you want to clue me > in to a ChangeLog commit that should be squashed with the previous > one, put SQUASH in the comment field. Don't alter the divider lines. > > I've found a single instance of my name in the file, which incidentally points to an edge case: I had modified the Changelog file itself (fixing the date of the entry). Perhaps this warrants a SQUASH. I've also scanned through the commits attributed to me in the new git repo, and I strongly suspect that some of those were not done by me. E.g. 63bc0f364a43d74ceca514a1954e2efa6c4ad7f6, dc3d0aa052b1af8563624f46516f27def76fdb80, and f2093b012b3b58842ae825439bfeec85b01fa8c3 are attributed to me but they were obviously committed by Bastian Maerkisch. (So I confirm his finding here). The reason indeed seems to be that unrelated changes by the same author, on the same day were squashed in the Changelog, and change-groups belonging to different authors, on the same day are listed in arbitrary order, even though this confuses the actual order of the changes. best regards, Peter Juhasz |
|
From: Eric S. R. <es...@th...> - 2017-10-18 21:31:21
|
Daniel J Sebald <dan...@ie...>: > The main issue still is the loss of branch information. I puzzled over this for a while - I can see all the branches here - then discovered I had busted my conversion script by parting in some instructions from SourceForge. Next spin will use git push --mirror as it should. > I'm looking into this amending of commit messages. I think it was Mojca who > said such things are possible, and yes it does look possible but it is a > rather advanced and rather clunky thing to do after the fact. With reposurgeon it's easy. Just fill in as many as you can of the comments in the file ENTRY. I can mechanically apply that to the repo in one step. > The tag modification isn't as complicated as the commit-message amending, > right? I think for tags we can easily use a git GUI to place a new tag > alongside the old tag, then delete the old tag. More work that it needs to be. Here's what my current set of renames looks like in reposurgeon: tag GNUPLOT_RELEASE_3_7_1 rename 3.7.1 tag GNUPLOT_RELEASE_3_7_2 rename 3.7.2 tag GNUPLOT_RELEASE_3_7_3 rename 3.7.3 tag Release_4_2_1 rename 4.2.1 tag Release_4_2_3 rename 4.2.3 tag Release_4_2_4 rename 4.2.4 tag Release_4_2_5 rename 4.2.5 tag Release_4_2_6 rename 4.2.6 tag Release_4_4_0 rename 4.4.0 tag Release_4_4_1 rename 4.4.1 tag Release_4_4_2 rename 4.4.2 tag Release_4_4_3 rename 4.4.3 tag Release_4_4_4 rename 4.4.4 tag Release_4_6_0 rename 4.6.0 tag Release_4_6_1 rename 4.6.1 tag Release_4_6_2 rename 4.6.2 tag Release_4_6_4 rename 4.6.4 tag Release_4_6_5 rename 4.6.5 tag Release_4_6_6 rename 4.6.6 tag Release_5_0_0 rename 5.0.0 tag Release_5_0_1 rename 5.0.1 tag Release_5_0_2 rename 5.0.2 tag Release_5_0_3 rename 5.0.3 tag Release_5_0_4 rename 5.0.4 tag Release_5_0_5 rename 5.0.5 tag Release_5_0_6 rename 5.0.6 tag Release_5_0_7 rename 5.0.7 tag Release_5_2_0 rename 5.2.0 tag Release_5_2_1 rename 5.2.1 It's that easy. > As for naming convention > I'll leave that up to others, but I would think that making the release tag > format the same as the tarball file name is most logical--whether the > tarball names should be changed, I don't know (could create confusion out > there in the Internet universe). Common thing to do in git-land is just to use the version number itself, as I've done above. But a different format, like 'gnuplot-5.2.1', would be easy to arrange. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. |
|
From: Bastian M. <bma...@we...> - 2017-10-18 20:25:38
|
Thank you for the new version. Overall the attribution algorithm seems to work remarkably well! There are a number of cases though were it fails. Here's an example (picked more or less randomly): https://sourceforge.net/p/gnuplot/git-main/ci/26f769db9e954052b11dbc8f242fc35a3cfd6880/ This one is attributed to Ethan, although the change is by me. The reason seems to be that the Changelog entry is inserted below an entry by Ethan on the same day. I think that is not an uncommon case, in fact I quickly found around a dozen such cases. Can this be taken into account or do we have to check manually? Another idea concerning the CVS conversion: at the early stages of the gnuplot CVS repo, files were moved from the top directory to sub-directories. That is they were deleted and added to CVS again. Hence the history before the move is kind of lost. While not super important, I wonder if this could be easily ammended now? Bastian > Gesendet: Mittwoch, 18. Oktober 2017 um 19:58 Uhr > Von: "Eric S. Raymond" <es...@th...> > An: gnu...@li... > Betreff: New spin of repository conversion > > I've pushed a version including the 1.1 release in its tail, and all > previously missing tags should now be visible. > > There are somewhere around 275 commits with empty comment fields. > These should either have comments filled in or, if they are ChanegLog > singletons that need to be glued to another clique, I need to know > that. > > I've enclosed a file named EMPTY which is in the right format to be > read back in by reposurgeon. All of you, please fill in any comments > you can in the commits you're responsible for; if you want to clue me > in to a ChangeLog commit that should be squashed with the previous > one, put SQUASH in the comment field. Don't alter the divider lines. > > The tags could use some cleanup. > > Many of the earlier BETA tags are junk at this point - due to > malformations in the CVS metadata they designate only incomplete sets > of files and don't point at a real (gitspace) commit. Instead they > point at synthetic commits generated by cvs-fast-export, but what > you'll get if you check out that commit is not reliably what was > originally intended. > > I've enclosed a list of these incomplete tags as BADTAGS. Also > a list of valid tags as GOODTAGS. > > My recommended disposition: first, delete all the bad tags. They're > not actually fit for purpose, and make the repo look like it can restore > state that it can't. > > (We may be able to deduce correct replacements for some of the bad tags > by comparing the history with saved release tarballs on SourceForge.) > > Second, change all the good release tags to use the same convention. In > git-land, normal practice is just to use the bare release number as a > release tag. So > > GNUPLOT_RELEASE_3_7_1 -> 3.7.1 > Release_4_4_2 -> 4.4.3 > -- > <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> > > My work is funded by the Internet Civil Engineering Institute: https://icei.org > Please visit their site and donate: the civilization you save might be your own. > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: Daniel J S. <dan...@ie...> - 2017-10-18 19:43:30
|
On 10/18/2017 12:58 PM, Eric S. Raymond wrote: > I've pushed a version including the 1.1 release in its tail, and all > previously missing tags should now be visible. The new repository clones much faster now. Thanks. Also, at first glance it appears that the authorship has mapped as expected. That's a nice achievement. The main issue still is the loss of branch information. That's something we have to retain. In gitg the graph shows no branches, and of course there are no branches other than "master" in the "Branches" list, since that's what caught my attention. However, in git-gui/gitk if I request "Visualize all branch history", the commit history graph does, in fact, show a bifurcation and different colors for branches, *but* it's only doing so for the 5.2 series branch, as oppose to going all the way back to 4.0 series. So, it looks to me as though the tag information is present, and the branch SHA information is present, but the very important head names for the branches has been lost. > There are somewhere around 275 commits with empty comment fields. > These should either have comments filled in or, if they are ChanegLog > singletons that need to be glued to another clique, I need to know > that. I'm looking into this amending of commit messages. I think it was Mojca who said such things are possible, and yes it does look possible but it is a rather advanced and rather clunky thing to do after the fact. It involves rebase, and I don't think we should have main developers doing too much rebase as it is really risky in terms of messing up the origin. Basically, rebase is like cutting "future" changesets from some trunk, and moving those future changesets to somewhere else in the repository. To change an old commit means rebasing at the particular location one wants to change the message, "amend" the message for that head of the trunk, and then put back the future changesets on top of that amended changeset. To do such a thing for 270 *** empty log message ***, is just out of the question. I was imagining there was some tool in a GUI that would easily amend an old commit message, but I don't think such an option exists. Eric, from your perspective, is this a difficult task modifying old commit messages at the time of construction if you were given a list of the following format? git log --format='<%cE!%cIZ> %s' For maintainers, a bit of discussion here about whether we should take the time right now to go back and fill in those commit messages that are empty. Here is how one would identify the missing messages: git log --format='<%cE!%cIZ> %s' | grep " empty log message " We'd have to redirect that output to a file and then manually edit the commit message for all those entries. And I think the easiest way to quickly jump to the changeset, with the diff hunks, is to use a git GUI (gitk, gitg, qgit, etc.) that has a search feature (in gitg, search for "empty log message"). > I've enclosed a file named EMPTY which is in the right format to be > read back in by reposurgeon. All of you, please fill in any comments > you can in the commits you're responsible for; if you want to clue me > in to a ChangeLog commit that should be squashed with the previous > one, put SQUASH in the comment field. Don't alter the divider lines. > > The tags could use some cleanup. The tag modification isn't as complicated as the commit-message amending, right? I think for tags we can easily use a git GUI to place a new tag alongside the old tag, then delete the old tag. As for naming convention I'll leave that up to others, but I would think that making the release tag format the same as the tarball file name is most logical--whether the tarball names should be changed, I don't know (could create confusion out there in the Internet universe). Dan |
|
From: Eric S. R. <es...@th...> - 2017-10-18 17:58:22
|
I've pushed a version including the 1.1 release in its tail, and all previously missing tags should now be visible. There are somewhere around 275 commits with empty comment fields. These should either have comments filled in or, if they are ChanegLog singletons that need to be glued to another clique, I need to know that. I've enclosed a file named EMPTY which is in the right format to be read back in by reposurgeon. All of you, please fill in any comments you can in the commits you're responsible for; if you want to clue me in to a ChangeLog commit that should be squashed with the previous one, put SQUASH in the comment field. Don't alter the divider lines. The tags could use some cleanup. Many of the earlier BETA tags are junk at this point - due to malformations in the CVS metadata they designate only incomplete sets of files and don't point at a real (gitspace) commit. Instead they point at synthetic commits generated by cvs-fast-export, but what you'll get if you check out that commit is not reliably what was originally intended. I've enclosed a list of these incomplete tags as BADTAGS. Also a list of valid tags as GOODTAGS. My recommended disposition: first, delete all the bad tags. They're not actually fit for purpose, and make the repo look like it can restore state that it can't. (We may be able to deduce correct replacements for some of the bad tags by comparing the history with saved release tarballs on SourceForge.) Second, change all the good release tags to use the same convention. In git-land, normal practice is just to use the bare release number as a release tag. So GNUPLOT_RELEASE_3_7_1 -> 3.7.1 Release_4_4_2 -> 4.4.3 -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. |
|
From: sfeam <sf...@us...> - 2017-10-18 14:40:21
|
On Wednesday, 18 October 2017 07:56:45 you wrote: > 17. okt. 2017 18:06 steam wrote: > > On Wednesday, 18 October 2017 02:12:51 Mojca Miklavec wrote: > > 17. okt. 2017 09:01 "Eric S. Raymond" wrote: > > > I would suggest unifying those names (perhaps to something like v5.2.rc0), > > but that can be done later. > > ??? > Sorry, I don't get it. > Why would you want to unify any of those? > > > Why would you want version 3.7.1 to be called GNUPLOT_RELEASE_3_7_1 and > version 5.2.1 to be called Release_5_2_1? Why not use something following > the same pattern for both? Like a simple v3.7.1/v5.2.1? Ah. I understand now. Rename them according to a unified scheme of names. Yes, that would make sense. I was confused about the reset of it. I realize now that all of the names listed were tag names, not separate branches. The list of branches would be much shorter, the important ones being the current development branch and the current stable branch. Sorry for the noise. Ethan > What I want is to be able to check them out separately. > > > Sure, changing the name won't disable it, but unless you unify names, > you'll have to check the exact name for each revision you'll want to > checkout. > > Everything labeled pre* or BETA* can be junked, but that is > not what I understand as "unify". > > Now maybe I just misunderstand the whole git thing. > Remember I'm new to this and thinking in terms of CVS. > What I'm thinking is that if I do > git checkout Release_5_0_7 > > I'll get the same files that were in the release tarball > gnuplot-5.0.7.tar.gz > > > No, you won't because the generated files (configure etc) are missing. On > Github one can attach files to tags though. > > And if for some reason we wanted to continue development of the 5.0 series > for a release 5.0.8, I could clone it (I don't know what git command that > is) > as a new branch Release_5_0_8 and push that one back to the repository. > Have I got that wrong? > > > You would checkout the branch 5.0, make changes to it and then tag a new > release. You would never make a 5.0.8 branch, only a tag. > > Mojca |
|
From: Achim G. <Str...@ne...> - 2017-10-18 08:17:49
|
Ethan A Merritt via gnuplot-beta writes: > I really don't know if this is correct or not. Me neither, but at least it provides the result I need for building gnuplot on Cygwin (with cygport) without explicit specififcation of TEXDIR. Cygport does set $prefix on invocation of the configury, so I did get an unexpected (and non-working) TEXDIR location. This is ion contrast to the openSUSE Linux distributions I consulted the build logs of their package for and the reason for the unexpected behaviour was that their build system apparently does not explicitly set $prefix (but must have the default prefix pointing to the system and not the local installation directories). > In my experience there are so many places that the TeX stuff might go, > your only hope is to manually specify where it is on the current > system. It doesn't help any that according to the man page "the > syntax for kpsexpand is incompatible with teTeX´s as of version 0.4" Ehm… teTex is unmaintained for over ten years now and was always suggested to be replaced by TeXLive, which is what all major distros and of course also Cygwin are using. > I read the existing ./configure logic to be that anything kpsexpand > returns is where things would be by default, but if you are specifying > a $prefix then you are overriding the default. > Does it ever make sense to mix the two? The generic $prefix should just decide which of potentially several install locations is chosen (eg. /usr, /usr/local, /opt, …). But in this test as originally written, specifying a $prefix (even if it's just repeating the default location) makes configure fall back to the "I don't know anything" branch that puts those files under an application specific directory. This is at least surprising, if not plain wrong. I have no idea if there's a better way to ask autotools about the proper location (I didn't find any pkg-config stuff for TeXLive), but it seems that this should be a problem that has already been solved elsewhere. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds |
|
From: Daniel J S. <dan...@ie...> - 2017-10-18 06:34:17
|
On 10/17/2017 08:05 PM, sfeam wrote: > On Wednesday, 18 October 2017 02:12:51 Mojca Miklavec wrote: >> 17. okt. 2017 09:01 "Eric S. Raymond" wrote: >> >> I see >> >> esr@snark:/mnt/vault/esr-vault/gnuplot/gnuplot$ git tag --list >> BETA_347_980925 >> BETA_347_981005 >> BETA_347_98101301 >> BETA_347_981121 >> BETA_348 >> BETA_348_981204 >> BETA_349 >> BETA_349_990114 >> GNUPLOT_19991210 >> GNUPLOT_20000330 >> GNUPLOT_37_20000507 >> GNUPLOT_990311 >> GNUPLOT_990312 >> GNUPLOT_990404 >> GNUPLOT_990507 >> GNUPLOT_990602 >> GNUPLOT_990612 >> GNUPLOT_990705 >> GNUPLOT_RELEASE_19991103 >> GNUPLOT_RELEASE_3_7_1 >> GNUPLOT_RELEASE_3_7_2 >> GNUPLOT_RELEASE_3_7_3 >> Release_4_2_1 >> Release_4_2_1-pre1 >> Release_4_2_3 >> Release_4_2_4 >> Release_4_2_5 >> Release_4_2_6 >> Release_4_4_0 >> Release_4_4_1 >> Release_4_4_2 >> Release_4_4_3 >> Release_4_4_4 >> Release_4_4_rc1 >> Release_4_6_0 >> Release_4_6_1 >> Release_4_6_2 >> Release_4_6_4 >> Release_4_6_5 >> Release_4_6_6 >> Release_4_6_rc1 >> Release_5_0_0 >> Release_5_0_1 >> Release_5_0_2 >> Release_5_0_3 >> Release_5_0_4 >> Release_5_0_5 >> Release_5_0_6 >> Release_5_0_7 >> Release_5_2_0 >> Release_5_2_1 >> axis-checkpoint-sourceforge-20000728 >> git-conversion >> gnuplot-3-8f >> gnuplot-4-4-alpha >> gnuplot-4-6-alpha >> gnuplot-5-0-rc2 >> gnuplot-5-2-rc0 >> pm3d-14 >> pre-lt-palette >> pre-macport >> pre-pm3d-02 >> pre-pm3d-11 >> >> >> I would suggest unifying those names (perhaps to something like v5.2.rc0), >> but that can be done later. > > ??? > Sorry, I don't get it. > Why would you want to unify any of those? > What I want is to be able to check them out separately. > > Everything labeled pre* or BETA* can be junked, but that is > not what I understand as "unify". I would think the tag names matching the tarball file name makes sense. In any case, this cleanup and naming convention can be dealt with later by Ethan, et al. as they gradually become comfortable with the commands of git. These details are best dealt with once we have an actual canonical repository. Think about it for now. Eric's concern should be more the things that can be automated in a script or whatnot. > Now maybe I just misunderstand the whole git thing. > Remember I'm new to this and thinking in terms of CVS. > What I'm thinking is that if I do > git checkout Release_5_0_7 > > I'll get the same files that were in the release tarball > gnuplot-5.0.7.tar.gz Generally you've got the right idea. > And if for some reason we wanted to continue development of the 5.0 series > for a release 5.0.8, I could clone it (I don't know what git command that is) > as a new branch Release_5_0_8 and push that one back to the repository. > Have I got that wrong? The terminology "clone" only applies to the whole repository. One clones the repository at the start, which brings everything onto their local computer; all changesets, hence all branches and all tags. Except for the push/pull associated with development to keep local and "origin" repositories in sync, the local and origin repository look exactly the same. That's why the word "clone" is used. This is what it means to be a "distributed" source control system. Every user has the whole history, not just some lone repository on a remote server. Just use "checkout", it works for branches, for tags, time stamps, file names (if one wants to toss file modifications). "checkout" is sort of the workhorse command of git. I suspect doing git checkout Release_5_0_7 checks out the "branch-5-0-stable" branch (or, I should say the pathway for which the head is "branch-5-0-stable") at the snapshot for the time associated with the tag. Right now, the in-progress repository doesn't have branches. We have to retain the branch structure from CVS, otherwise we are stuck as far as patching/back-porting fixes in recent versions. For example, see the graph in the gitg GUI I posted here: http://www.dansebald.com/gnuplot/cvsimport_conversion_Screenshot_from_2017-10-17_11-52-18.png which has branch-4-0-stable, branch-4-2-stable, etc. We want the in-progress repository looking like that. Dan |
28 messages has been excluded from this view by a project administrator.
