Menu
▾
▴
gnuplot-beta
|
From: sfeam <sf...@us...> - 2017-11-16 06:20:24
|
Version 5.2.2 ============= A tarball for release 5.2.2 is now in the usual place on sf.net: https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.2/ This will be the last gnuplot release prepared from the CVS repository. Anything you commit to cvs between now and whenever sourceforge pulls the plug on it will not make it into future gnuplot releases. cvs->git conversion =================== A snapshot of the cvs repository from 04-November-2017 was converted to git with the help of Eric S Raymond [Thanks!] Since then we have been evaluating the state of the converted source tree. At the moment there are two copies on sf.net, one slightly cleaner than the other. A handful of commits have gone in to these, but it remains true that the existing git content on sf.net may be wiped clean and re-created from the 04-Nov-2017 snapshot if we find that there were annoying but correctable errors from the previous conversion[s]. So far the "correctable" part has been a sticking point. plans ===== I will be travelling for most of the next month, so I would prefer that we make a yes/no decision by next Monday (20 November) as to whether the current converted code base is good enough to work with. If it is not, then the repository is likely to remain volatile until at least the end of the year. You'll be able to read from it, but if you make copies you may have to rebase or re-clone if we do the entire conversion over again. But really I think it all looks promising. Not perfect but "good enough". Questions ========= I'm still learning how to rethink my work flow for git, so please help me out. For instance, does it make any sense to continue to maintain the ChangeLog file? So far I'm having little success in keeping it in sync with the git commit messages. Is there some tool to help with that, or is the normal practice with git to rely only on the commit messages? I know you can dump a log of commits, so I guess one possibility is to use that to update the ChangeLog every now and then (1 month intervals? 6 months?) but not try to touch it for every commit. Advice? Ethan |
|
From: Eric S. R. <es...@th...> - 2017-11-16 07:44:25
|
sfeam <sf...@us...>: > But really I think it all looks promising. > Not perfect but "good enough". I'm available to help with any dinal changes that need to be made. I believe you big decision is whether drop the somewjat incorrect 3.7 branch - tip content doesn't match the tarballs. I recommend dropping it. > Questions > ========= > > I'm still learning how to rethink my work flow for git, so please > help me out. For instance, does it make any sense to continue > to maintain the ChangeLog file? So far I'm having little success in > keeping it in sync with the git commit messages. Is there some > tool to help with that, or is the normal practice with git to rely > only on the commit messages? I know you can dump a log of commits, > so I guess one possibility is to use that to update the ChangeLog every > now and then (1 month intervals? 6 months?) but not try to touch it > for every commit. Advice? I recommend no longer keeping a ChangeLog. In fact. I recommend deleting it from the tip version. It will, of course, still be available to anyone who cares to check out the last pre-conversion revision. In the presence of changeset comments with author attributions. Changelog comments are duplicative and the requirement to do them becomes increasingly annoying. Better to write changeset comments and browse those with gitk or equivalent. -- <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: Dima K. <gn...@di...> - 2017-11-16 08:50:05
|
Eric S. Raymond <es...@th...> writes: > sfeam <sf...@us...>: > >> I'm still learning how to rethink my work flow for git, so please >> help me out. For instance, does it make any sense to continue >> to maintain the ChangeLog file? So far I'm having little success in >> keeping it in sync with the git commit messages. Is there some >> tool to help with that, or is the normal practice with git to rely >> only on the commit messages? I know you can dump a log of commits, >> so I guess one possibility is to use that to update the ChangeLog every >> now and then (1 month intervals? 6 months?) but not try to touch it >> for every commit. Advice? > > I recommend no longer keeping a ChangeLog. In fact. I recommend deleting it > from the tip version. It will, of course, still be available to anyone > who cares to check out the last pre-conversion revision. > > In the presence of changeset comments with author attributions. Changelog > comments are duplicative and the requirement to do them becomes increasingly > annoying. Better to write changeset comments and browse those with > gitk or equivalent. Agreed. My feeling is that you want some sort of NEWS file that describes a very high-level list of changes so that somebody can clearly see the big differences between releases. But for finer-grained stuff, the version control should be the master record. |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2017-11-16 21:25:48
|
Am 16.11.2017 um 08:44 schrieb Eric S. Raymond: > I believe you big decision is whether drop the somewjat incorrect 3.7 > branch - tip content doesn't match the tarballs. That's not a problem. Almost none of our branch tip matches the last tarball made from the same branch, because we kept porting bug fixes over onto those branches, but never made a "final" release on them afterwards. The converted histories I've looked at still managed to reproduce every single tarball we compared them to essentially perfectly, i.e. with all remaining differences easily explained as the result of "make dist" or some manual tinkering by the person preparing the release. cvs-fast-export found all artificial changes needed to reach these goals itself --- it just had to do somewhat too many of those for our tastes, i.e. the change sets marked as " This splintered the initial imported set of pre-SourceForge gnuplot sources into three groups of files: *) Files that were never changed at all since the import (demo *.dat files, almost all of them) who really still live on the vendor branch today (CVS revisions is 1.1.1.<n>), but are magically shifted onto the trunk by cvs-fast-export. *) Files that were modified at least once before the 3.7 branch. They get the vendor branch as an orphaned branch anchored at the start of git history, but otherwise just work fine, because nothing of interest happened on the vendor branch. *) Files that were modified both on the mainline the first time after the 3.7 branch was started, and at least once on the 3.7 branch itself. It's these latter one that cause the real problem with the 3.7 branch, I think. Their history has branches splitting off the vendor branch, and cvs-fast-export just does not handle those at all. > In the presence of changeset comments with author attributions. Changelog > comments are duplicative and the requirement to do them becomes increasingly > annoying. I don't fully agree with that. ChangeLog entries, at least properly filled-out GNU-style ones like we've been trying to do, are considerably more detailed than the typical git check-in comment. They mention source file, function, and details of the modification. IOW, while commit messages usually only describe what the goal of a change was, and some of the better ones also outline the implementation, they rarely detail how exactly that goal was achieved. Actions like "git blame" or "git log" can replace some of that (and being performed locally they're a lot faster than "cvs annotate", too), yet I'm not sure they can truly replace the information content of a well-maintained ChangeLog. It might work if we could agree that commit messages for gnuplot will be required to include a full ChangeLog-format block (except the header line) in their bottom part. That would make it possible to generate a proper ChangeLog ex post, e.g. at release time. |
|
From: Daniel J S. <dan...@ie...> - 2017-11-16 10:24:12
|
On 11/16/2017 12:17 AM, sfeam via gnuplot-beta wrote: > Version 5.2.2 > ============= > > A tarball for release 5.2.2 is now in the usual place on sf.net: > https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.2/ > This will be the last gnuplot release prepared from the CVS repository. > > Anything you commit to cvs between now and whenever sourceforge pulls > the plug on it will not make it into future gnuplot releases. > > cvs->git conversion > =================== > > A snapshot of the cvs repository from 04-November-2017 was converted > to git with the help of Eric S Raymond [Thanks!] > Since then we have been evaluating the state of the converted source tree. > At the moment there are two copies on sf.net, one slightly cleaner than > the other. A handful of commits have gone in to these, but it remains > true that the existing git content on sf.net may be wiped clean and > re-created from the 04-Nov-2017 snapshot if we find that there were > annoying but correctable errors from the previous conversion[s]. > So far the "correctable" part has been a sticking point. > > plans > ===== > > I will be travelling for most of the next month, so I would prefer that > we make a yes/no decision by next Monday (20 November) as to whether the > current converted code base is good enough to work with. If it is not, > then the repository is likely to remain volatile until at least the end > of the year. You'll be able to read from it, but if you make copies > you may have to rebase or re-clone if we do the entire conversion over > again. > > But really I think it all looks promising. > Not perfect but "good enough". I've sent a script file in a previous post that can be used to compare CVS versions to git versions, about two dozen of them. One can see precisely what the differences are (almost all log/RCSid related). I described in detail the major discrepancy I've found surrounding version 4.6.3 in a previous post. I've also pointed out in detail that the git repository goes out of synch with the CVS repository very early on. Rather than bringing branches in synch at the branch points, the best thing would be to bring the master branch in synch as early as possible. Retaining the early tags in git repository would have assisted in comparing earliest tagged versions between the repositories and identifying where the earliest differences are. (Just add to the list of files in the automated script file I sent previously.) I'm not sure where the notion that 3.7 branch series is corrupted and doesn't match a tarball is originating from. I'd prefer someone attach a diff file to illustrate the differences before discarding anything. Here's the clone that I have: [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = https://git.code.sf.net/p/gnuplot/git-main fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master and I've downloaded gnuplot-3.7.3.tar.gz from gnuplot's download site. What follows is the differences (all RCSid/Log details in the comments section, i.e., not important as the code itself is the same.): sebald@ ~/gnuplot/git_repository $ diff -ur '--exclude=.git' -I '\$[A-Z]*[a-z]*' gnuplot-git/ ~/src/gnuplot-3.7.3/ diff -ur '--exclude=.git' -I '\$[A-Z]*[a-z]*' gnuplot-git/docs/old/ChangeLog.old /home/sebald/src/gnuplot-3.7.3/docs/old/ChangeLog.old --- gnuplot-git/docs/old/ChangeLog.old 2017-11-11 14:34:39.319799009 -0600 +++ /home/sebald/src/gnuplot-3.7.3/docs/old/ChangeLog.old 1998-11-16 07:07:33.000000000 -0600 @@ -8,7 +8,10 @@ * working. This means that the revision numbers in the individual files * do not agree with the one in the log. I hope to fix this some time soon. * - * $Log: version.c,v $ + * $Log: ChangeLog.old,v $ + * Revision 1.1 1998/11/16 13:07:33 lhecking + * Moved from version.c. + * * * I have moved these entries from version.c. All future code changes * should be logged in ChangeLog. Lars Hecking diff -ur '--exclude=.git' -I '\$[A-Z]*[a-z]*' gnuplot-git/docs/old/makefile.r /home/sebald/src/gnuplot-3.7.3/docs/old/makefile.r --- gnuplot-git/docs/old/makefile.r 2017-11-16 03:19:23.971387193 -0600 +++ /home/sebald/src/gnuplot-3.7.3/docs/old/makefile.r 2002-01-26 12:55:02.000000000 -0600 @@ -1,7 +1,10 @@ -# $Id: makefile.r,v 1.1 1998/12/09 17:24:30 lhecking Exp $ +# $Id: makefile.r,v 1.1.2.1 2002/01/26 18:55:02 lhecking Exp $ # # $Log: makefile.r,v $ +# Revision 1.1.2.1 2002/01/26 18:55:02 lhecking +# Support for pdf and W3C Scalable Vector Graphics output. +# # Revision 1.1 1998/12/09 17:24:30 lhecking # Moved from ../.. # diff -ur '--exclude=.git' -I '\$[A-Z]*[a-z]*' gnuplot-git/docs/old/README.3p5 /home/sebald/src/gnuplot-3.7.3/docs/old/README.3p5 --- gnuplot-git/docs/old/README.3p5 2017-11-16 03:19:23.919387193 -0600 +++ /home/sebald/src/gnuplot-3.7.3/docs/old/README.3p5 1998-11-16 07:01:23.000000000 -0600 @@ -1,9 +1,12 @@ This is a bugfix to version 3.4. -# $Id: README.3p5,v 1.1 1993/09/27 17:07:30 alex Exp $ +# $Id: README.3p5,v 1.1 1998/11/16 13:01:23 lhecking Exp $ # # $Log: README.3p5,v $ +# Revision 1.1 1998/11/16 13:01:23 lhecking +# Moved from top level dir. +# # Revision 1.1 1993/09/27 17:07:30 alex # gnuplot 3.5 release # Only in gnuplot-git/: .gitignore > Questions > ========= > > I'm still learning how to rethink my work flow for git, so please > help me out. For instance, does it make any sense to continue > to maintain the ChangeLog file? So far I'm having little success in > keeping it in sync with the git commit messages. Is there some > tool to help with that, or is the normal practice with git to rely > only on the commit messages? I know you can dump a log of commits, > so I guess one possibility is to use that to update the ChangeLog every > now and then (1 month intervals? 6 months?) but not try to touch it > for every commit. Advice? That's possible, but after a month of using git you'll likely wonder, Why update a ChangeLog? Typing "git log | less" is just as easy as "less ChangeLog" and the git command works in all subdirectories. Keep the same format for the git log messages as you've been using for the ChangeLog, i.e., -> One line of "short-log" -> List of files that have changed, just like CVS ChangeLog entries After you are used to git, move the ChangeLog files to some subdirectory "historic_cvs" or something. The entries still apply to the history, and the ChangeLog files can be searched but in a more cumbersome way than using gitk/qgit/gitg funnel searching. If you are happy with just looking at the diffs in the ChangeLog for every commit in the git repository, then deleting the ChangeLogs from the master is fine too. Somehow I think it is better just tucking the ChangeLog files in some subfolder. You'll need to come up with a work flow that incorporates what tools you are used to, e.g., any special editor for looking at patch files, etc. Things to keep in mind. 1) Ask the people submitting patches, via their git tools to include the file change info in their log messages, using the existing git repository changesets as examples. 2) Code submitters will generate their changeset and extract it into a patch file, changeset header and all. 3) One option is to apply that patch to your local repository and test. If you feel the patch is good, then push to the canonical version. If it isn't quite ready, you'll have to learn how to reset your local copy (i.e., toss out the applied changeset). 4) Say you aren't quite happy with the code in the changeset, but it is close or you want to clean up the person's changeset log message. One option is to edit the changeset/patch file directly. Sometimes convenient, but sometimes not if it is a complex change. 5) The changeset file that people submit will look exactly like a typical patch file, except at the top will be extra git SHA, author info, log message, etc. in "comments" section. So, another option is to not import the submitter's changeset, but instead just use the normal "patch" command as you are used to. (You may need -p0 or -p1 in the patch command to get rid of that first level a/ and b/ that git puts in place.) Hit the reset button within git-gui, gitg or qgit, and you will then see the changes that the submitter is proposing. This then makes the workflow something very similar to the way you would go about your own changesets. But then you'll need to learn how to commit the submitters changes and supply the author info from the submitters patch file. 6) Remember all of this is local, so if you make a mistake only recognized after doing a commit, you can easily reset that commit back to the staged file status prior to the erroneous commit and redo with corrections. Or, you may discard all changes with "git checkout". Once you have one or more changesets that you are satisfied with locally, then use "git push" to put them in the canonical repository. 7) You are going to eventually run into cases in which the commit that you make and push to the canonical repository will conflict with some changeset that another developer pushed, e.g., you edited some of the same files and same code lines as another user. That is, the diff-hunks of the changesets interfere with one another. Git tries its best to merge, but sometimes it is confused and you'll have to manually tell git how to resolve conflicts. You'll need a merge tool for best visualization of exactly what's happening. KDE might have a merge tool already setup, or look for "meld" which is pretty nice. Dan |
|
From: Petr M. <mi...@ph...> - 2017-11-16 15:37:27
|
I see a trouble with missing ChangeLog that you cannot see what has been done unless you download everything. Or is there something like git log --oneline https://git.code.sf.net/... (without "git clone")? If ChangeLog is to be omitted, then I propose it is not empty but contains: ChangeLog is not maintained after repository conversion to git. Please use git blabla to see the latest changes. For gnuplot releases, I propose to generate ChangeLog from git, so that the changes wrt last release are visible (except for the NEWS file). > incorrect 3.7 branch - tip content doesn't match the tarballs Then we can release 3.7.4 in order to have git and .tar.gz synchronized. It can be just a .tar.gz release. --- PM |
|
From: sfeam <sf...@us...> - 2017-11-16 16:40:15
|
On Thursday, 16 November 2017 04:23:58 Daniel J Sebald wrote: > On 11/16/2017 12:17 AM, sfeam via gnuplot-beta wrote: > > cvs->git conversion > > =================== > > > > A snapshot of the cvs repository from 04-November-2017 was converted > > to git with the help of Eric S Raymond [Thanks!] > > Since then we have been evaluating the state of the converted source tree. > > At the moment there are two copies on sf.net, one slightly cleaner than > > the other. A handful of commits have gone in to these, but it remains > > true that the existing git content on sf.net may be wiped clean and > > re-created from the 04-Nov-2017 snapshot if we find that there were > > annoying but correctable errors from the previous conversion[s]. > > So far the "correctable" part has been a sticking point. > > > > I've sent a script file in a previous post that can be used to compare > CVS versions to git versions, about two dozen of them. One can see > precisely what the differences are (almost all log/RCSid related). I > described in detail the major discrepancy I've found surrounding version > 4.6.3 in a previous post. Do you have a script to correct those discrepancies? As I tried to imply, it's the correction stage that seems to be hard. > > Questions > > ========= > > > > I'm still learning how to rethink my work flow for git, so please > > help me out. For instance, does it make any sense to continue > > to maintain the ChangeLog file? So far I'm having little success in > > keeping it in sync with the git commit messages. Is there some > > tool to help with that, or is the normal practice with git to rely > > only on the commit messages? I know you can dump a log of commits, > > so I guess one possibility is to use that to update the ChangeLog every > > now and then (1 month intervals? 6 months?) but not try to touch it > > for every commit. Advice? > > That's possible, but after a month of using git you'll likely wonder, > Why update a ChangeLog? Typing "git log | less" is just as easy as > "less ChangeLog" and the git command works in all subdirectories. That will only take you back as far as the cvs->git conversion date. When trying to track down a bug I often need to hunt back all the way into the version 4 development series. That history is captured in the ChangeLog files but so far as I know is never going to be retrieved by a git command. The existing conversion does not turn the old ChangeLog text into commit messages so "git log" won't see them. Or maybe I'm missing some clever search command other than "git log"? Ethan > Keep the same format for the git log messages as you've been using for > the ChangeLog, i.e., > > -> One line of "short-log" > -> List of files that have changed, just like CVS ChangeLog entries > > After you are used to git, move the ChangeLog files to some subdirectory > "historic_cvs" or something. The entries still apply to the history, > and the ChangeLog files can be searched but in a more cumbersome way > than using gitk/qgit/gitg funnel searching. If you are happy with just > looking at the diffs in the ChangeLog for every commit in the git > repository, then deleting the ChangeLogs from the master is fine too. > Somehow I think it is better just tucking the ChangeLog files in some > subfolder. > > You'll need to come up with a work flow that incorporates what tools you > are used to, e.g., any special editor for looking at patch files, etc. > Things to keep in mind. > > 1) Ask the people submitting patches, via their git tools to include the > file change info in their log messages, using the existing git > repository changesets as examples. > > 2) Code submitters will generate their changeset and extract it into a > patch file, changeset header and all. > > 3) One option is to apply that patch to your local repository and test. > If you feel the patch is good, then push to the canonical version. If > it isn't quite ready, you'll have to learn how to reset your local copy > (i.e., toss out the applied changeset). > > 4) Say you aren't quite happy with the code in the changeset, but it is > close or you want to clean up the person's changeset log message. One > option is to edit the changeset/patch file directly. Sometimes > convenient, but sometimes not if it is a complex change. > > 5) The changeset file that people submit will look exactly like a > typical patch file, except at the top will be extra git SHA, author > info, log message, etc. in "comments" section. So, another option is to > not import the submitter's changeset, but instead just use the normal > "patch" command as you are used to. (You may need -p0 or -p1 in the > patch command to get rid of that first level a/ and b/ that git puts in > place.) Hit the reset button within git-gui, gitg or qgit, and you will > then see the changes that the submitter is proposing. This then makes > the workflow something very similar to the way you would go about your > own changesets. But then you'll need to learn how to commit the > submitters changes and supply the author info from the submitters patch > file. > > 6) Remember all of this is local, so if you make a mistake only > recognized after doing a commit, you can easily reset that commit back > to the staged file status prior to the erroneous commit and redo with > corrections. Or, you may discard all changes with "git checkout". Once > you have one or more changesets that you are satisfied with locally, > then use "git push" to put them in the canonical repository. > > 7) You are going to eventually run into cases in which the commit that > you make and push to the canonical repository will conflict with some > changeset that another developer pushed, e.g., you edited some of the > same files and same code lines as another user. That is, the diff-hunks > of the changesets interfere with one another. Git tries its best to > merge, but sometimes it is confused and you'll have to manually tell git > how to resolve conflicts. You'll need a merge tool for best > visualization of exactly what's happening. KDE might have a merge tool > already setup, or look for "meld" which is pretty nice. > > Dan > > ------------------------------------------------------------------------------ > 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-11-16 17:20:11
|
On 11/16/2017 10:37 AM, sfeam wrote: > On Thursday, 16 November 2017 04:23:58 Daniel J Sebald wrote: >> On 11/16/2017 12:17 AM, sfeam via gnuplot-beta wrote: > >>> cvs->git conversion >>> =================== >>> >>> A snapshot of the cvs repository from 04-November-2017 was converted >>> to git with the help of Eric S Raymond [Thanks!] >>> Since then we have been evaluating the state of the converted source tree. >>> At the moment there are two copies on sf.net, one slightly cleaner than >>> the other. A handful of commits have gone in to these, but it remains >>> true that the existing git content on sf.net may be wiped clean and >>> re-created from the 04-Nov-2017 snapshot if we find that there were >>> annoying but correctable errors from the previous conversion[s]. >>> So far the "correctable" part has been a sticking point. >>> >> >> I've sent a script file in a previous post that can be used to compare >> CVS versions to git versions, about two dozen of them. One can see >> precisely what the differences are (almost all log/RCSid related). I >> described in detail the major discrepancy I've found surrounding version >> 4.6.3 in a previous post. > > Do you have a script to correct those discrepancies? > As I tried to imply, it's the correction stage that seems to be hard. No script (I thought that git conversion was already complete, that's why I put SHAs in the sample commands). Here are steps (all very simple) that can be done after the conversion is complete: " Given that, it looks like you'll need to add something there to get release 4.6.3 in line with the tarball. And the easiest thing is probably to mimic what cvs2git did as follows: 1) Create a branch from "bump patchlevel to 4.6.3" version git checkout c21a99aa6caecac5f125219e791665953c816b37 git checkout -b Release_4_6_3_tarball_stub (or some similar name) 2) Merge changeset "fix memory allocation for large matrices" to the newly created stub branch: git cherry-pick 7d0989dd8cf3b3c18a1fa7181c8a1d38ab14d0b3 3) Change the tags as follows (where the indentation means a different branch, however the viewer chooses to display the graph): [4.6.3] fix memory allocation for large matrices Ethan A Merritt [4.6.3-Windows] fix memory allocation for large matrices Ethan A Merritt Release 4.6 patchlevel 3 Bastian Maerkisch bump patchlevel to 4.6.3 Ethan A Merritt *** empty log message *** Ethan A Merritt That is, delete tag [4.6.3] and add a new tag [4.6.3] on the new branch (stub) which has the patch. This puts version tagged [4.6.3] in line with cvs-repository and the tarball. Add a new tag [4.6.3-Windows] to signify that is the release that Bastian has published for 4.6.3 that includes everything in the 4.6.3 tagged version plus the mods to four Windows-related files. " >>> Questions >>> ========= >>> >>> I'm still learning how to rethink my work flow for git, so please >>> help me out. For instance, does it make any sense to continue >>> to maintain the ChangeLog file? So far I'm having little success in >>> keeping it in sync with the git commit messages. Is there some >>> tool to help with that, or is the normal practice with git to rely >>> only on the commit messages? I know you can dump a log of commits, >>> so I guess one possibility is to use that to update the ChangeLog every >>> now and then (1 month intervals? 6 months?) but not try to touch it >>> for every commit. Advice? >> >> That's possible, but after a month of using git you'll likely wonder, >> Why update a ChangeLog? Typing "git log | less" is just as easy as >> "less ChangeLog" and the git command works in all subdirectories. > > That will only take you back as far as the cvs->git conversion date. I know. When this conversion began, I immediately brainstormed on ways we might incorporate all the historic ChangeLog info into a "git log" printout. That idea was rejected, probably for the better because chronological order could not be maintained exactly. > When trying to track down a bug I often need to hunt back all > the way into the version 4 development series. That history is captured > in the ChangeLog files but so far as I know is never going to be retrieved > by a git command. That's why I suggested not removing the ChangeLogs entirely from the repository but instead keeping them handy by moving them into some folder "historic_cvs" which obviously indicates that workflow is no longer in use, because it is otherwise cumbersome to checkout an old version of code just to retrieve the historic ChangeLog files. Plus some people are used to using "grep" for searching and grep is always nice (it's effectively the same as qgit's funnel search feature). But if you want to maintain a ChangeLog, then don't do that. However, certainly having the current ChangeLog workflow in the git commit message itself has the advantage of quick searching within qgit (definitely want that). In any case, maintaining the same info in different places is always fraught with inadvertently going out of synch. > The existing conversion does not turn the old ChangeLog > text into commit messages so "git log" won't see them. > Or maybe I'm missing some clever search command other than "git log"? qgit allows fast funnel searching on Author, SHA, log message, etc. But there is also a slower search of the whole repository diff hunks. So if one is very detailed about the historic ChangeLog phrases to search for, matches will appear in one of the diff hunks for the ChangeLog file itself. So, searching the historic ChangeLog is still possible, but probably in a much more roundabout way. Dan |
|
From: Daniel J S. <dan...@ie...> - 2017-11-17 10:18:28
|
On 11/17/2017 02:29 AM, Bastian Märkisch wrote: >> >> We seem to be talking past each other. >> I do not care about further tweaks to the tags or branches. >> Their conversion is sufficiently good. >> >> The remaining issue is incorrectly converted timestamp and author > attribution. >> I found a script that automates a recipe that is basically >> > (snip) >> >> However I tried using this recipe to make one change and it failed. >> The filter-branch step spit out progress updates for about half an hour >> and then died. Repository too large or too complicated? >> Some issue with branch structure that is non-fatal form most purposes but > trips >> up this specific operation? >> Whatever, it doesn't work. >> >> The other alternative is to use reposurgeon during, rather than after, the >> conversion. Bastian was having problems with that path also. >> >> Ethan >> > > What I have been trying to do is to manually add author changes to the Eric > Raymond's reconvert script. The example command given was: > <es...@th...!2017-11-04T16:44:25> setfield author "Frd J. Foonly > <fr...@fo...>" > (which according to the docs probably should instead be > <2017-11-04T16:44:25! es...@th...> setfield author "Frd J. Foonly > <fr...@fo...>" > > Unfortunately, such commands do not "find" the entry, not even with the tip > version of reposurgeon. > So I am kind of stuck for the moment. There can't be a space in the search field <2017-11-04T16:44:25! es...@th...> I'm assuming you don't have any in what you are searching for. You are likely running into what I ran into with experimenting with tags, the time-zone factor. You must specify the exact time in the search field <>, but often git displays some kind of time zone-adjusted. So I had to do trial and error shifting by 7 hours to put times in GMT, e.g., <2013-04-11T20:04:07Z>. (Note the added Z...search Zulu time in Wikipedia: https://en.wikipedia.org/wiki/Time_zone ) For example, doing the git log as you suggested, I see a time 2000-10-20T20:01:32+01:00 which would be 2000-10-20T20:01:32Z I think. Anyway, I used git times from qgit that didn't have that extra UTC offset value so I often had to compute the proper UTC time and rarely got it right on the first try. Dan |
|
From: Bastian M. <bma...@we...> - 2017-11-18 09:19:53
|
> > What I have been trying to do is to manually add author changes to the Eric > > Raymond's reconvert script. The example command given was: > > <es...@th...!2017-11-04T16:44:25> setfield author "Frd J. Foonly > > <fr...@fo...>" > > (which according to the docs probably should instead be > > <2017-11-04T16:44:25! es...@th...> setfield author "Frd J. Foonly > > <fr...@fo...>" > > > > Unfortunately, such commands do not "find" the entry, not even with the tip > > version of reposurgeon. > > So I am kind of stuck for the moment. > > There can't be a space in the search field <2017-11-04T16:44:25! > es...@th...> I'm assuming you don't have any in what you are > searching for. Sure. No spaces. > > You are likely running into what I ran into with experimenting with > tags, the time-zone factor. You must specify the exact time in the > search field <>, but often git displays some kind of time zone-adjusted. > So I had to do trial and error shifting by 7 hours to put times in > GMT, e.g., <2013-04-11T20:04:07Z>. (Note the added Z...search Zulu time > in Wikipedia: > > https://en.wikipedia.org/wiki/Time_zone > > ) > > For example, doing the git log as you suggested, I see a time > > 2000-10-20T20:01:32+01:00 > > which would be > > 2000-10-20T20:01:32Z > > I think. Anyway, I used git times from qgit that didn't have that extra > UTC offset value so I often had to compute the proper UTC time and > rarely got it right on the first try. > > Dan That did the trick! You just have to subtract the time offset to get the "Zulu" time. Thanks for the pointer. I thought I had tried that before though.... Bastian |
|
From: Dima K. <gn...@di...> - 2017-11-16 18:28:31
|
Daniel J Sebald <dan...@ie...> writes:
> On 11/16/2017 12:17 AM, sfeam via gnuplot-beta wrote:
>
> Keep the same format for the git log messages as you've been using for
> the ChangeLog, i.e.,
>
> -> One line of "short-log"
> -> List of files that have changed, just like CVS ChangeLog entries
>
> <snip>
>
> 1) Ask the people submitting patches, via their git tools to include the
> file change info in their log messages
Please, let's not do that. Version control already has this information,
and asking humans to replicate it is both effortfull and error-prone.
Does 'git log --stat' give you what you want?
> 2) Code submitters will generate their changeset and extract it into a
> patch file, changeset header and all.
Can we use 'git format'?
> 3) One option is to apply that patch to your local repository and test.
> If you feel the patch is good, then push to the canonical version. If
> it isn't quite ready, you'll have to learn how to reset your local copy
> (i.e., toss out the applied changeset).
>
> 4) Say you aren't quite happy with the code in the changeset, but it is
> close or you want to clean up the person's changeset log message. One
> option is to edit the changeset/patch file directly. Sometimes
> convenient, but sometimes not if it is a complex change.
Many potential workflows here. You can ask the submitter to resolve the
issues and to resubmit the patch. Or you can apply the patch as is ('git
am' would import the patch and all the metadata from a 'git format'-ted
patch), make changes, and then do something like 'git commit --amend -C
HEAD'. If we care, git allows you to separate the author and committer.
|
|
From: Daniel J S. <dan...@ie...> - 2017-11-16 18:47:50
|
On 11/16/2017 12:28 PM, Dima Kogan wrote: > Daniel J Sebald <dan...@ie...> writes: > >> On 11/16/2017 12:17 AM, sfeam via gnuplot-beta wrote: >> >> Keep the same format for the git log messages as you've been using for >> the ChangeLog, i.e., >> >> -> One line of "short-log" >> -> List of files that have changed, just like CVS ChangeLog entries >> >> <snip> >> >> 1) Ask the people submitting patches, via their git tools to include the >> file change info in their log messages > > Please, let's not do that. Version control already has this information, > and asking humans to replicate it is both effortfull and error-prone. > Does 'git log --stat' give you what you want? It doesn't. Stat tells you what files have changed, but it doesn't indicate why. As an example, here is what is done for Octave: http://hg.savannah.gnu.org/hgweb/octave/rev/f8c263f961c1 Are the main developers going to maintain the ChangeLog-like formatted messages? (It's up to them, does it help in tracking down where a code change may have happened? Apparently, as they've been doing just that for quite some time.) If so, why not ask the contributor to do that work rather than the main developers? And the benefit of asking the contributor to do a more detailed log message is that I believe it makes the code less error-prone, not more. Why? Because when it comes time to create a commit and I have to write a slightly more detailed log message I'm forced to review my code diffs to describe it, and very often I realize there is a slightly better syntax or there is a comment or debugging line I forgot to remove. Describing/reviewing one's code is like using proof-reading or spell-checking. Dan |
|
From: Tait <gnu...@t4...> - 2017-11-17 01:55:53
|
> >> 1) Ask the people submitting patches, via their git tools to include the > >> file change info in their log messages > > > > Please, let's not do that. Version control already has this information, > > and asking humans to replicate it is both effortfull and error-prone. > > Does 'git log --stat' give you what you want? > > It doesn't. Stat tells you what files have changed, but it doesn't > indicate why. As an example, here is what is done for Octave: > > http://hg.savannah.gnu.org/hgweb/octave/rev/f8c263f961c1 > > ... I feel like the change log duplicates the history in git itself, as Dima has argued. One thing to keep in mind is that git allows, even encourages, smaller commits. Things that might have been a single commit before would be treated as a branch (called "feature-branch") in git. Because a whole series of commits can be pushed at once, there's no reason to combine connected-but- discrete pieces into one commit. Take the Octave commit as an example: *) Create shared_ptr branch *) commit 1 message: "Remove base_graphics_object:count" followed by an explanation of why it's being removed, and any concerns or considerations regarding its removal *) Commit 2: Use default constructors/destructors for <____> Again, the latter part of the commit message should cover the "why?", because it's not clear why the defaults weren't being used before. *) Commit 3: Change rep to shared_ptr A plain pointer is problematic because ... etc. The shared_ptr conversion requires all direct assignments to rep be replaced with ... etc. *) merge shared_ptr to master *) [optional] delete shared_ptr branch Then this 3-commit branch gets pushed and merged back (or fast-forwarded) into master all at once. If some part of this proves later to introduce a regression, having smaller commits makes it easier to bisect and identify precisely the problem. And I can't imagine what a change log would add above and beyond what's there already. As to the proofreading, I find I naturally do this in between my local commits and pushing them to a remote. I always use a combination of diffstat/log/show to review what I'm about to push -- to make sure I'm pushing what I think, and as a last chance to catch bad formatting or other errors. Once pushed, it can't be taken back or rewritten, so a little extra care helps. |
|
From: Ethan A M. <sf...@us...> - 2017-11-16 20:08:11
|
On Thursday, November 16, 2017 9:19:52 AM PST Daniel J Sebald wrote: > On 11/16/2017 10:37 AM, sfeam wrote: > > On Thursday, 16 November 2017 04:23:58 Daniel J Sebald wrote: > >> On 11/16/2017 12:17 AM, sfeam via gnuplot-beta wrote: > > > >>> cvs->git conversion > >>> =================== > >>> > >>> A snapshot of the cvs repository from 04-November-2017 was converted > >>> to git with the help of Eric S Raymond [Thanks!] > >>> Since then we have been evaluating the state of the converted source tree. > >>> At the moment there are two copies on sf.net, one slightly cleaner than > >>> the other. A handful of commits have gone in to these, but it remains > >>> true that the existing git content on sf.net may be wiped clean and > >>> re-created from the 04-Nov-2017 snapshot if we find that there were > >>> annoying but correctable errors from the previous conversion[s]. > >>> So far the "correctable" part has been a sticking point. > >>> > >> > >> I've sent a script file in a previous post that can be used to compare > >> CVS versions to git versions, about two dozen of them. One can see > >> precisely what the differences are (almost all log/RCSid related). I > >> described in detail the major discrepancy I've found surrounding version > >> 4.6.3 in a previous post. > > > > Do you have a script to correct those discrepancies? > > As I tried to imply, it's the correction stage that seems to be hard. > > No script (I thought that git conversion was already complete, that's > why I put SHAs in the sample commands). Here are steps (all very > simple) that can be done after the conversion is complete: We seem to be talking past each other. I do not care about further tweaks to the tags or branches. Their conversion is sufficiently good. The remaining issue is incorrectly converted timestamp and author attribution. I found a script that automates a recipe that is basically [from StackOverflow] %%%%%%%% Assume for clarity of exposition that 03f482d6 is the commit whose author we are trying to replace, and 42627abe is the commit with the new author. Checkout the commit we are trying to modify. git checkout 03f482d6 Make the author change. git commit --amend --author "New Author Name <New Author Email>" Replace the old commit with the new one locally. git replace 03f482d6 42627abe Rewrite all future commits based on the replacement. git filter-branch -- --all Remove the replacement for cleanliness. git replace -d 03f482d6 Push the new history (only use --force if the below fails, and only after sanity checking with git log and/or git diff). git push --force-with-lease %%%%%%%%% However I tried using this recipe to make one change and it failed. The filter-branch step spit out progress updates for about half an hour and then died. Repository too large or too complicated? Some issue with branch structure that is non-fatal form most purposes but trips up this specific operation? Whatever, it doesn't work. The other alternative is to use reposurgeon during, rather than after, the conversion. Bastian was having problems with that path also. Ethan |
|
From: Daniel J S. <dan...@ie...> - 2017-11-16 20:50:32
|
On 11/16/2017 02:07 PM, Ethan A Merritt wrote: > On Thursday, November 16, 2017 9:19:52 AM PST Daniel J Sebald wrote: >> On 11/16/2017 10:37 AM, sfeam wrote: >>> On Thursday, 16 November 2017 04:23:58 Daniel J Sebald wrote: >>>> On 11/16/2017 12:17 AM, sfeam via gnuplot-beta wrote: >>> >>>>> cvs->git conversion >>>>> =================== >>>>> >>>>> A snapshot of the cvs repository from 04-November-2017 was converted >>>>> to git with the help of Eric S Raymond [Thanks!] >>>>> Since then we have been evaluating the state of the converted source tree. >>>>> At the moment there are two copies on sf.net, one slightly cleaner than >>>>> the other. A handful of commits have gone in to these, but it remains >>>>> true that the existing git content on sf.net may be wiped clean and >>>>> re-created from the 04-Nov-2017 snapshot if we find that there were >>>>> annoying but correctable errors from the previous conversion[s]. >>>>> So far the "correctable" part has been a sticking point. >>>>> >>>> >>>> I've sent a script file in a previous post that can be used to compare >>>> CVS versions to git versions, about two dozen of them. One can see >>>> precisely what the differences are (almost all log/RCSid related). I >>>> described in detail the major discrepancy I've found surrounding version >>>> 4.6.3 in a previous post. >>> >>> Do you have a script to correct those discrepancies? >>> As I tried to imply, it's the correction stage that seems to be hard. >> >> No script (I thought that git conversion was already complete, that's >> why I put SHAs in the sample commands). Here are steps (all very >> simple) that can be done after the conversion is complete: > > We seem to be talking past each other. > I do not care about further tweaks to the tags or branches. > Their conversion is sufficiently good. Easy to do. Modifying tags and applying changesets at other locations in branches is all legit stuff to do in a git repository. > The remaining issue is incorrectly converted timestamp and author attribution. > I found a script that automates a recipe that is basically > > [from StackOverflow] What is the link, so we may see the context? > %%%%%%%% > Assume for clarity of exposition that 03f482d6 is the commit > whose author we are trying to replace, and 42627abe is the commit > with the new author. > > Checkout the commit we are trying to modify. > git checkout 03f482d6 > > Make the author change. > git commit --amend --author "New Author Name <New Author Email>" > > Replace the old commit with the new one locally. > git replace 03f482d6 42627abe > > Rewrite all future commits based on the replacement. > git filter-branch -- --all > > Remove the replacement for cleanliness. > git replace -d 03f482d6 > > Push the new history (only use --force if the below fails, and only after > sanity checking with git log and/or git diff). > git push --force-with-lease > %%%%%%%%% > > However I tried using this recipe to make one change and it failed. > The filter-branch step spit out progress updates for about half an hour > and then died. Repository too large or too complicated? > Some issue with branch structure that is non-fatal form most purposes > but trips up this specific operation? > Whatever, it doesn't work. That doesn't seem like something one would typically want to do in a functioning git repo. It's sort of getting to those real powerful but also baneful git commands. One thing to keep in mind in a distributed source control system is it's best to not undo anything in the canonical version and not do anything structurally inconsistent with what other users have locally on their systems. For example, after the fact changing authors means that other users' local git repo may no longer match the canonical version in a fundamental/bad way. That is, if the change will mean that others will have to discard their local git repo and reclone the canonical version, then it should only be done in the most extreme and necessary cases. Now, I see a "git commit" in the list of commands above, and git tries to be good about making a change of this sort as a new changeset. But even the documentation raises some caveats: https://git-scm.com/docs/git-commit#git-commit---amend " You should understand the implications of rewriting history if you amend a commit that has already been published. (See the "RECOVERING FROM UPSTREAM REBASE" section in git-rebase[1].) " I could look into this in more detail, but it sounds like an angels-fear-to-tread sort of thing. > The other alternative is to use reposurgeon during, rather than after, > the conversion. Bastian was having problems with that path also. If in the conversion process one wants to alter an author/committer entry at the very last step, i.e., "I found this particular changeset that should have author XYZ rather than ABC", git fast-import needs three files: blob.dat dump.dat marks.dat If one CAREFULLY edits the dump.dat file in a normal ASCII editor (or use string editor sed), one can change something like author Lars Hecking <xxxxxx@xxxxxx> 892314000 +0000 committer Lars Hecking <xxxxxx@xxxxxx> 892669391 +0000 to author Buster Keaton <xxxxxx@xxxxxx> 892314000 +0000 committer Lars Hecking <xxxxxx@xxxxxx> 892669391 +0000 as the very last step. I emphasize carefully because any mismatch in item order or even white space will make git fast-import fail. Dan |
|
From: Ethan A M. <sf...@us...> - 2017-11-16 21:16:30
|
On Thursday, November 16, 2017 12:50:06 PM PST Daniel J Sebald wrote: > On 11/16/2017 02:07 PM, Ethan A Merritt wrote: > > The remaining issue is incorrectly converted timestamp and author attribution. > > I found a script that automates a recipe that is basically > > > > [from StackOverflow] > > What is the link, so we may see the context? https://stackoverflow.com/questions/3042437/change-commit-author-at-one-specific-commit/30737248 > > %%%%%%%% > > Assume for clarity of exposition that 03f482d6 is the commit > > whose author we are trying to replace, and 42627abe is the commit > > with the new author. > > > > Checkout the commit we are trying to modify. > > git checkout 03f482d6 > > > > Make the author change. > > git commit --amend --author "New Author Name <New Author Email>" > > > > Replace the old commit with the new one locally. > > git replace 03f482d6 42627abe > > > > Rewrite all future commits based on the replacement. > > git filter-branch -- --all > > > > Remove the replacement for cleanliness. > > git replace -d 03f482d6 > > > > Push the new history (only use --force if the below fails, and only after > > sanity checking with git log and/or git diff). > > git push --force-with-lease > > %%%%%%%%% > > > > However I tried using this recipe to make one change and it failed. > > The filter-branch step spit out progress updates for about half an hour > > and then died. Repository too large or too complicated? > > Some issue with branch structure that is non-fatal form most purposes > > but trips up this specific operation? > > Whatever, it doesn't work. > > That doesn't seem like something one would typically want to do in a > functioning git repo. 1) This is not typical 2) This is not [yet] a functioning git repo We're looking for procedures to set up a git repository in the first instance so that it contains a "history" of transactions that actually happened somewhere else in a foreign language subject to faulty translation. Ethan > It's sort of getting to those real powerful but > also baneful git commands. One thing to keep in mind in a distributed > source control system is it's best to not undo anything in the canonical > version and not do anything structurally inconsistent with what other > users have locally on their systems. For example, after the fact > changing authors means that other users' local git repo may no longer > match the canonical version in a fundamental/bad way. That is, if the > change will mean that others will have to discard their local git repo > and reclone the canonical version, then it should only be done in the > most extreme and necessary cases. > > Now, I see a "git commit" in the list of commands above, and git tries > to be good about making a change of this sort as a new changeset. But > even the documentation raises some caveats: > > https://git-scm.com/docs/git-commit#git-commit---amend > > " > You should understand the implications of rewriting history if you amend > a commit that has already been published. (See the "RECOVERING FROM > UPSTREAM REBASE" section in git-rebase[1].) > " > > I could look into this in more detail, but it sounds like an > angels-fear-to-tread sort of thing. > > > > The other alternative is to use reposurgeon during, rather than after, > > the conversion. Bastian was having problems with that path also. > > If in the conversion process one wants to alter an author/committer > entry at the very last step, i.e., "I found this particular changeset > that should have author XYZ rather than ABC", git fast-import needs > three files: > > blob.dat > dump.dat > marks.dat > > If one CAREFULLY edits the dump.dat file in a normal ASCII editor (or > use string editor sed), one can change something like > > author Lars Hecking <xxxxxx@xxxxxx> 892314000 +0000 > committer Lars Hecking <xxxxxx@xxxxxx> 892669391 +0000 > > to > > author Buster Keaton <xxxxxx@xxxxxx> 892314000 +0000 > committer Lars Hecking <xxxxxx@xxxxxx> 892669391 +0000 > > as the very last step. I emphasize carefully because any mismatch in > item order or even white space will make git fast-import fail. > > Dan > > ------------------------------------------------------------------------------ > 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-11-16 21:36:51
|
On 11/16/2017 03:14 PM, Ethan A Merritt wrote: > On Thursday, November 16, 2017 12:50:06 PM PST Daniel J Sebald wrote: >> On 11/16/2017 02:07 PM, Ethan A Merritt wrote: > >>> The remaining issue is incorrectly converted timestamp and author attribution. >>> I found a script that automates a recipe that is basically >>> >>> [from StackOverflow] >> >> What is the link, so we may see the context? > > https://stackoverflow.com/questions/3042437/change-commit-author-at-one-specific-commit/30737248 > >>> %%%%%%%% >>> Assume for clarity of exposition that 03f482d6 is the commit >>> whose author we are trying to replace, and 42627abe is the commit >>> with the new author. >>> >>> Checkout the commit we are trying to modify. >>> git checkout 03f482d6 >>> >>> Make the author change. >>> git commit --amend --author "New Author Name <New Author Email>" >>> >>> Replace the old commit with the new one locally. >>> git replace 03f482d6 42627abe >>> >>> Rewrite all future commits based on the replacement. >>> git filter-branch -- --all >>> >>> Remove the replacement for cleanliness. >>> git replace -d 03f482d6 >>> >>> Push the new history (only use --force if the below fails, and only after >>> sanity checking with git log and/or git diff). >>> git push --force-with-lease >>> %%%%%%%%% >>> >>> However I tried using this recipe to make one change and it failed. >>> The filter-branch step spit out progress updates for about half an hour >>> and then died. Repository too large or too complicated? >>> Some issue with branch structure that is non-fatal form most purposes >>> but trips up this specific operation? >>> Whatever, it doesn't work. >> >> That doesn't seem like something one would typically want to do in a >> functioning git repo. > > 1) This is not typical > 2) This is not [yet] a functioning git repo > > We're looking for procedures to set up a git repository in the first > instance so that it contains a "history" of transactions that actually > happened somewhere else in a foreign language subject to faulty > translation. OK, so it's not as simple as changing some text in the blob.dat file, but instead there should be some extra commits put in place? git checkout 03f482d6 git commit --amend --author "New Author Name <New Author Email>" I don't think the above works the way you are thinking. --amend only applies to the most recent change, or possibly tip of a branch. That link above is suggesting something like the following: say there is E D C B A commits. If I take the recent changes and temporarily rebase them (i.e., disconnect) to some indefinite location E D C B A I can then treat B as though it is the most recent commit and apply the familiar --amend step. There needs to be that disconnect before --amend can be applied. The "git rebase -i B" is some funky interactive command that sequentially steps through changesets to allow altering a series of changesets. Dan |
|
From: Bastian M. <bma...@we...> - 2017-11-17 08:39:37
|
>
> We seem to be talking past each other.
> I do not care about further tweaks to the tags or branches.
> Their conversion is sufficiently good.
>
> The remaining issue is incorrectly converted timestamp and author
attribution.
> I found a script that automates a recipe that is basically
>
(snip)
>
> However I tried using this recipe to make one change and it failed.
> The filter-branch step spit out progress updates for about half an hour
> and then died. Repository too large or too complicated?
> Some issue with branch structure that is non-fatal form most purposes but
trips
> up this specific operation?
> Whatever, it doesn't work.
>
> The other alternative is to use reposurgeon during, rather than after, the
> conversion. Bastian was having problems with that path also.
>
> Ethan
>
What I have been trying to do is to manually add author changes to the Eric
Raymond's reconvert script. The example command given was:
<es...@th...!2017-11-04T16:44:25> setfield author "Frd J. Foonly
<fr...@fo...>"
(which according to the docs probably should instead be
<2017-11-04T16:44:25! es...@th...> setfield author "Frd J. Foonly
<fr...@fo...>"
Unfortunately, such commands do not "find" the entry, not even with the tip
version of reposurgeon.
So I am kind of stuck for the moment.
Typical cases where this becomes necessary to correctly attribute the code
change:
* Missing ChangeLog entry to go along with the code commit (but
maybe added later in a separate commit)
* ChangeLog modifications to additional author lines that make
reposurgeon pick the wrong line
* (Copy/paste) Errors of the author / date line (incorrect date
and/or author)
For a list of easy-to-spot candidates see e.g. the output of
git log -i --grep "patch.*by" --format="%aI %ae %ce %s" | awk "{ if
(\$2 == \$3) { print \$0 } }"
This selects all commits which have a "patch by" in the commit message but
the committer is identical to the claimed author. Other "suspects" can be
found with "patch from" or "SF patch #" / "Patch #".
All in all I so far identified <100 author attributions which could be
amended.
Personally, I think we should get these corrected - if reasonably possible.
But my time at the moment is limited. Maybe locating the /commit message/ or
the mailbox_in commands would work here, but I haven't tested that yet.
Bastian
|
|
From: sfeam <sf...@us...> - 2017-11-17 17:20:10
|
On Friday, 17 November 2017 09:29:12 Bastian Märkisch wrote:
> >
> > We seem to be talking past each other.
> > I do not care about further tweaks to the tags or branches.
> > Their conversion is sufficiently good.
> >
> > The remaining issue is incorrectly converted timestamp and author
> attribution.
> > I found a script that automates a recipe that is basically
> >
> (snip)
> >
> > However I tried using this recipe to make one change and it failed.
> > The filter-branch step spit out progress updates for about half an hour
> > and then died. Repository too large or too complicated?
> > Some issue with branch structure that is non-fatal form most purposes but
> trips
> > up this specific operation?
> > Whatever, it doesn't work.
> >
> > The other alternative is to use reposurgeon during, rather than after, the
> > conversion. Bastian was having problems with that path also.
> >
> > Ethan
> >
>
> What I have been trying to do is to manually add author changes to the Eric
> Raymond's reconvert script. The example command given was:
> <es...@th...!2017-11-04T16:44:25> setfield author "Frd J. Foonly
> <fr...@fo...>"
> (which according to the docs probably should instead be
> <2017-11-04T16:44:25! es...@th...> setfield author "Frd J. Foonly
> <fr...@fo...>"
>
> Unfortunately, such commands do not "find" the entry, not even with the tip
> version of reposurgeon.
> So I am kind of stuck for the moment.
>
> Typical cases where this becomes necessary to correctly attribute the code
> change:
> * Missing ChangeLog entry to go along with the code commit (but
> maybe added later in a separate commit)
> * ChangeLog modifications to additional author lines that make
> reposurgeon pick the wrong line
> * (Copy/paste) Errors of the author / date line (incorrect date
> and/or author)
>
> For a list of easy-to-spot candidates see e.g. the output of
>
> git log -i --grep "patch.*by" --format="%aI %ae %ce %s" | awk "{ if
> (\$2 == \$3) { print \$0 } }"
That gets me 3 hits over the last 10 years, about 30 (including 20 false
positives) going back to the turn of the century, and finally a bunch of
indirect attributions from 1998/1999.
To me that seems like a very low number of problem cases.
More to the point, are these even errors? They correctly indicate the
original author of the patch. If you trace a code change back to one of
these commit messages, you will indeed learn who it came from.
I had thought your concern was that there were cases where the conversion
script had mis-matched the ChangeLog entry with the corresponding set
of patches and therefore listed them as coming from whoever had made
the previous, or subsequent, log entry. If there are such mis-matches,
it would require a different sort of search to find them.
Ethan
> This selects all commits which have a "patch by" in the commit message but
> the committer is identical to the claimed author. Other "suspects" can be
> found with "patch from" or "SF patch #" / "Patch #".
> All in all I so far identified <100 author attributions which could be
> amended.
>
> Personally, I think we should get these corrected - if reasonably possible.
> But my time at the moment is limited. Maybe locating the /commit message/ or
> the mailbox_in commands would work here, but I haven't tested that yet.
>
> Bastian
|
|
From: Dima K. <gn...@di...> - 2017-11-16 21:32:29
|
Daniel J Sebald <dan...@ie...> writes: > On 11/16/2017 12:28 PM, Dima Kogan wrote: >> Daniel J Sebald <dan...@ie...> writes: >> >>> On 11/16/2017 12:17 AM, sfeam via gnuplot-beta wrote: >>> >>> Keep the same format for the git log messages as you've been using for >>> the ChangeLog, i.e., >>> >>> -> One line of "short-log" >>> -> List of files that have changed, just like CVS ChangeLog entries >>> >>> <snip> >>> >>> 1) Ask the people submitting patches, via their git tools to include the >>> file change info in their log messages >> >> Please, let's not do that. Version control already has this information, >> and asking humans to replicate it is both effortfull and error-prone. >> Does 'git log --stat' give you what you want? > > It doesn't. Stat tells you what files have changed, but it doesn't > indicate why. As an example, here is what is done for Octave: > > http://hg.savannah.gnu.org/hgweb/octave/rev/f8c263f961c1 > > Are the main developers going to maintain the ChangeLog-like formatted > messages? (It's up to them, does it help in tracking down where a code > change may have happened? Apparently, as they've been doing just that > for quite some time.) If so, why not ask the contributor to do that > work rather than the main developers? > > And the benefit of asking the contributor to do a more detailed log > message is that I believe it makes the code less error-prone, not more. > Why? Because when it comes time to create a commit and I have to write > a slightly more detailed log message I'm forced to review my code diffs > to describe it, and very often I realize there is a slightly better > syntax or there is a comment or debugging line I forgot to remove. > Describing/reviewing one's code is like using proof-reading or > spell-checking. I'm all for detailed log messages, but I feel strongly that requiring rigid Changelog-like commit messages is counterproductive. If the patch is convoluted-enough such that it requires detailed documentation about every modified function, and this documentation doesn't belong in a comment for some reason, then sure, put whatever is helpful into the log message. I will argue, however, than this case is more an exception than the rule. And I think your linked commit illustrates this point: most of that commit message is clearly seen from the content of the diff. And the message is intended to help out humans, then it's actually too terse. This format somehow ends up being both verbose-enough to be a major pain, but terse-enough to be unhelpful. And as a sporadic contributor to multiple projects, I DREAD those that have pointless and rigid style requirements. PLEASE don't throw in obstacles for new contributors. |
|
From: Daniel J S. <dan...@ie...> - 2017-11-16 21:59:51
|
On 11/16/2017 03:32 PM, Dima Kogan wrote: > Daniel J Sebald <dan...@ie...> writes: > >> On 11/16/2017 12:28 PM, Dima Kogan wrote: >>> Daniel J Sebald <dan...@ie...> writes: >>> >>>> On 11/16/2017 12:17 AM, sfeam via gnuplot-beta wrote: >>>> >>>> Keep the same format for the git log messages as you've been using for >>>> the ChangeLog, i.e., >>>> >>>> -> One line of "short-log" >>>> -> List of files that have changed, just like CVS ChangeLog entries >>>> >>>> <snip> >>>> >>>> 1) Ask the people submitting patches, via their git tools to include the >>>> file change info in their log messages >>> >>> Please, let's not do that. Version control already has this information, >>> and asking humans to replicate it is both effortfull and error-prone. >>> Does 'git log --stat' give you what you want? >> >> It doesn't. Stat tells you what files have changed, but it doesn't >> indicate why. As an example, here is what is done for Octave: >> >> http://hg.savannah.gnu.org/hgweb/octave/rev/f8c263f961c1 >> >> Are the main developers going to maintain the ChangeLog-like formatted >> messages? (It's up to them, does it help in tracking down where a code >> change may have happened? Apparently, as they've been doing just that >> for quite some time.) If so, why not ask the contributor to do that >> work rather than the main developers? >> >> And the benefit of asking the contributor to do a more detailed log >> message is that I believe it makes the code less error-prone, not more. >> Why? Because when it comes time to create a commit and I have to write >> a slightly more detailed log message I'm forced to review my code diffs >> to describe it, and very often I realize there is a slightly better >> syntax or there is a comment or debugging line I forgot to remove. >> Describing/reviewing one's code is like using proof-reading or >> spell-checking. > > I'm all for detailed log messages, but I feel strongly that requiring > rigid Changelog-like commit messages is counterproductive. If the patch > is convoluted-enough such that it requires detailed documentation about > every modified function, and this documentation doesn't belong in a > comment for some reason, then sure, put whatever is helpful into the log > message. I will argue, however, than this case is more an exception than > the rule. But if everyone uses their own style of documentation, how are people searching log messages (in qgit or whatever) and reading the summaries supposed to quickly formulate what has changed and where. One is looking to quickly find the info, not try to figure out everyone's style of presenting information, or to go searching every code change. Instead it's, "Ah, this looks like the changeset where the bug came in, so now I will look more closely at the diff hunks themselves." Furthermore, I believe there are editors/pagers that will highlight the format that gnuplot has been using because it is rigid and known. > And I think your linked commit illustrates this point: most of that > commit message is clearly seen from the content of the diff. And the > message is intended to help out humans, then it's actually too terse. > This format somehow ends up being both verbose-enough to be a major > pain, but terse-enough to be unhelpful. Other entries aren't as terse and give more insight. And often some files are excluded if it was some insignificant change like a comment or typo. > And as a sporadic contributor to multiple projects, I DREAD those that > have pointless and rigid style requirements. PLEASE don't throw in > obstacles for new contributors. I didn't say if there is a new contributor unfamiliar with the process that their changeset file (or even a plain patch file) should be completely discarded because s/he didn't follow the rules. But its easier for the person writing the changes to summarize them than to have the reviewer do so. Spending five minutes on a log message is a problem after spending two-plus hours on a modification and testing? Dan |
|
From: Dima K. <gn...@di...> - 2017-11-16 22:21:43
|
Daniel J Sebald <dan...@ie...> writes: >> I'm all for detailed log messages, but I feel strongly that requiring >> rigid Changelog-like commit messages is counterproductive. If the patch >> is convoluted-enough such that it requires detailed documentation about >> every modified function, and this documentation doesn't belong in a >> comment for some reason, then sure, put whatever is helpful into the log >> message. I will argue, however, than this case is more an exception than >> the rule. > > But if everyone uses their own style of documentation, how are people > searching log messages (in qgit or whatever) and reading the summaries > supposed to quickly formulate what has changed and where. One is > looking to quickly find the info, not try to figure out everyone's style > of presenting information, or to go searching every code change. > Instead it's, "Ah, this looks like the changeset where the bug came in, > so now I will look more closely at the diff hunks themselves." > Furthermore, I believe there are editors/pagers that will highlight the > format that gnuplot has been using because it is rigid and known. This argument seems so foreign to me that I don't even know how to respond exactly. What information are you hoping to get from Changelog-style text that you don't get in other ways? Filenames? 'git log --stat' gives you that Function names? 'git show' gives you that Rationale for the change? This should be granular not to a particular function but to the commit as a whole, and if needed, there should be an essay accompanying the commit message. If your descriptions are granular to each function, then maybe your commit isn't fine-grained enough, and should be split up. Are you against comments because they aren't structured? >> And as a sporadic contributor to multiple projects, I DREAD those that >> have pointless and rigid style requirements. PLEASE don't throw in >> obstacles for new contributors. > > I didn't say if there is a new contributor unfamiliar with the process > that their changeset file (or even a plain patch file) should be > completely discarded because s/he didn't follow the rules. But its > easier for the person writing the changes to summarize them than to have > the reviewer do so. Spending five minutes on a log message is a problem > after spending two-plus hours on a modification and testing? Unambiguously: yes, it is a problem. When I'm spending hours on fixing and testing things, I'm working on issues that need to be solved. I like fixing things, and contributing ever-so-slightly to openly-available tooling. If I have to think about people's arbitrary (and to me, pointless) stylistic whims, then I feel like I'm wasting my time. |
|
From: Bastian M. <bma...@we...> - 2017-11-18 08:24:53
|
> Version 5.2.2 > ============= > > A tarball for release 5.2.2 is now in the usual place on sf.net: > https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.2/ > This will be the last gnuplot release prepared from the CVS repository. > > Anything you commit to cvs between now and whenever sourceforge pulls > the plug on it will not make it into future gnuplot releases. > Windows 32bit and 64bit binary packages are now available on SF as installer packages or in 7z format. The installers claim a minimum requirement of Vista SP2 (but need the "feature upgrade"), but this may or may not be true since I cannot test. Earliest version tested is Windows 7 SP2. Bastian |
|
From: Bastian M. <bma...@we...> - 2017-11-19 19:40:08
|
> > > What I have been trying to do is to manually add author changes to the Eric > > > Raymond's reconvert script. The example command given was: > > > <es...@th...!2017-11-04T16:44:25> setfield author "Frd J. Foonly > > > <fr...@fo...>" > > > (which according to the docs probably should instead be > > > <2017-11-04T16:44:25! es...@th...> setfield author "Frd J. Foonly > > > <fr...@fo...>" > > > > > > Unfortunately, such commands do not "find" the entry, not even with the tip > > > version of reposurgeon. > > > So I am kind of stuck for the moment. (snip) > > You are likely running into what I ran into with experimenting with > > tags, the time-zone factor. You must specify the exact time in the > > search field <>, but often git displays some kind of time zone-adjusted. > > So I had to do trial and error shifting by 7 hours to put times in > > GMT, e.g., <2013-04-11T20:04:07Z>. (Note the added Z...search Zulu time > > in Wikipedia: > > > > https://en.wikipedia.org/wiki/Time_zone > > > > ) > > > > For example, doing the git log as you suggested, I see a time > > > > 2000-10-20T20:01:32+01:00 > > > > which would be > > > > 2000-10-20T20:01:32Z > > > > I think. Anyway, I used git times from qgit that didn't have that extra > > UTC offset value so I often had to compute the proper UTC time and > > rarely got it right on the first try. > > > > Dan > > That did the trick! You just have to subtract the time offset to get the "Zulu" time. > Thanks for the pointer. I thought I had tried that before though.... > > Bastian > Although the "setfield" lines now work, adding such statements to reconvert seems to break the repository conversion: reposurgeon: exporting...fatal: Expected committer but didn't get opne I am giving up. The automatic ChangeLog conversion does a great job. As far as I can tell there are <100 manual attribution changes we could argue about. Ethan, the repo "gnuplot-trunk" was in my opinion converted using an older version of Eric Raymond's script which got the attribution wrong if the ChangeLog change did not include the author line. There are quite a number of these. E.g. there are ~120 of your committs which claim I am the author. But this is only true for very few of them: git log --committer=Ethan --author=Bastian --oneline So - in my opinion - one further iteration of conversion is in order. Bastian |
|
From: sfeam <sf...@us...> - 2017-11-19 20:12:11
|
On Sunday, 19 November 2017 20:39:57 Bastian Märkisch wrote: > Although the "setfield" lines now work, adding such statements to reconvert seems to > break the repository conversion: > > reposurgeon: exporting...fatal: Expected committer but didn't get opne > > I am giving up. The automatic ChangeLog conversion does a great job. As far as I can > tell there are <100 manual attribution changes we could argue about. > > Ethan, the repo "gnuplot-trunk" was in my opinion converted using an older version > of Eric Raymond's script which got the attribution wrong if the ChangeLog change did > not include the author line. There are quite a number of these. E.g. there are ~120 > of your committs which claim I am the author. But this is only true for very few of > them: > git log --committer=Ethan --author=Bastian --oneline > So - in my opinion - one further iteration of conversion is in order. I used a version that Eric sent me on 04-Nov-2017. I have not seen a newer version. Is there one? Ethan |
