On 2016-12-14 21:35-0800 Alan W. Irwin wrote: > One issue you should be aware of is git blame results are obfuscated > by our code styling events (often triggered by me) which amount to > putting random blanks in the code to make it conform to our style. > > So > > software@raven> git blame bindings/wxwidgets/wxPLplotwindow.h |grep '2\.8' > 39a6c01b (Alan W. Irwin 2015-02-14 19:32:12 -0800 90) //We use connect > instead of Bind for compatiblity with wxWidgets 2.8 > 39a6c01b (Alan W. Irwin 2015-02-14 19:32:12 -0800 123) //on at least one > system (CentOS with intel compiler and wxWidgets 2.8.12). > > "shows" I was the author of the above comment in commit 39a6c01b, but > that was a styling commit so you have to back off one commit to 39a6c01b^ to > find the true > author/commit which then shows the following: > > software@raven> git blame 39a6c01b^ bindings/wxwidgets/wxPLplotwindow.h |grep > '2\.8' > cf59c54a (Phil Rosenberg 2015-01-15 14:18:42 +0000 75) //We use > connect instead of Bind for compatiblity with wxWidgets 2.8 > fa121bd5 (Phil Rosenberg 2015-01-20 15:56:53 +0000 102) //on at least > one system (CentOS with intel compiler and wxWidgets 2.8.12).
Never mind. I learn something new about git every week it seems. Which is why this subject line is "git blog" again. I just now discovered the -w option ignores whitespace for git blame. So we have the following result (note there is no specification required of the commit prior to a style event) software@raven> git blame -w bindings/wxwidgets/wxPLplotwindow.h |grep '2\.8' cf59c54a (Phil Rosenberg 2015-01-15 14:18:42 +0000 90) //We use connect instead of Bind for compatiblity with wxWidgets 2.8 fa121bd5 (Phil Rosenberg 2015-01-20 15:56:53 +0000 123) //on at least one system (CentOS with intel compiler and wxWidgets 2.8.12). So that -w option is extraordinarily useful for us (because of all our whitespace style changes). Of course, this also illustrates one of my principal gripes with git which is the inconsistent option names. So to ignore whitespace for diffs, use either -w or --ignore-all-space, but to do that same thing for git blame use -w only. git blame does accept --ignore-all-space, but it ignores it silently which is a bug that should be fixed. (Either accept the option and use it, or reject the option, but do not silently ignore it.) So to be really provactive here, because of such option inconsistencies and bugs, it is possible git might be the CVS of _distributed_ version control systems. Eventually CVS, the premier centralized version control system was replaced in just a few years by something much slicker and consistent (svn). Does that slicker and consistent git already exist, and is the git demise therefore just around the corner? Of course, to return to reality the two cases are obviously not parallel. CVS probably would have continued to be virtually the only centralized version control system if there had been a development team to support it, but its original developer(s) abandoned it and which left a vacuum for the svn development team to populate. My understanding is git continues to have an active development team. So it is likely going to be around for a very long time. But I sure wish those git developers made a point of systematically cleaning up the many inconsistent option names that are used (to return to my principal git gripe). Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
