Menu
▾
▴
gnuplot-beta
|
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: 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 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: Juhász P. <pet...@gm...> - 2017-10-18 22:08:20
Attachments:
EMPTY
|
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 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: 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: 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: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: 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: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: 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: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: 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: 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: Bastian M. <bma...@we...> - 2017-10-19 19:12:24
|
> > 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? > If you look at http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/?hideattic=0&pathr ev=MAIN there are a number of files marked "dead" deleted by Lars Hecking with a commit comment "Moved to ..." Similarily for /NeXT/, /beos/, /win/, /os2/. I was wondering if the history of these files could be prepended (again) to the history of the destination files. That is if that is easy enough. That part of the history was "lost" some 18y ago ;) Bastian > 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. > > > > ---------------------------------------------------------------------------- -- > 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: Eric S. R. <es...@th...> - 2017-10-19 19:51:20
|
Bastian Märkisch <bma...@we...>: > > Can you be more specific about the time this happened, and in what way the > > git conversion fails to reflect the old history? > > > > If you look at > http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/?hideattic=0&pathr > ev=MAIN > there are a number of files marked "dead" deleted by Lars Hecking with a > commit > comment "Moved to ..." Similarily for /NeXT/, /beos/, /win/, /os2/. I was > wondering > if the history of these files could be prepended (again) to the history of > the destination > files. That is if that is easy enough. That part of the history was "lost" > some 18y ago ;) This probably didn't lose any history at all. If these were moved back to their original locations later, then both moves will be part of the gitspace history. Frankly, if this has gone wrong, I'd be very nervous about trying to fix it. CVS is flaky enough even when used as intended; moving around or otherwise messing with master files behind CVS's back tends to make very bad things happen. -- <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-23 18:05:14
|
> > > Can you be more specific about the time this happened, and in what > > > way the git conversion fails to reflect the old history? > > > > > > > If you look at > > http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/?hideattic=0 > > &pathr > > ev=MAIN > > there are a number of files marked "dead" deleted by Lars Hecking with > > a commit comment "Moved to ..." Similarily for /NeXT/, /beos/, /win/, > > /os2/. I was wondering if the history of these files could be > > prepended (again) to the history of the destination files. That is if > > that is easy enough. That part of the history was "lost" > > some 18y ago ;) > > This probably didn't lose any history at all. If these were moved back to their > original locations later, then both moves will be part of the gitspace history. > It is "lost" because the moved files and the deletes were committed in subsequent commits. So git cannot interpret that as a "move" operation. That happened in a sequence committed by Lars Hecking on 1999-03-26 at 22:32:57 - 23:19:32 (11 commits labelled "Moved from <dirold>." or "Moved to <dirnew>."). Any chance of "merging" these commits? (But the other issues are way more important). Bastian > Frankly, if this has gone wrong, I'd be very nervous about trying to fix it. CVS is > flaky enough even when used as intended; moving around or otherwise > messing with master files behind CVS's back tends to make very bad things > happen. |
