bugGNU roff - Bugs: bug #60654, mdate.pl should use git...

 
 

bug #60654: mdate.pl should use git modification times if possible

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Sat 22 May 2021 03:18:42 AM UTC
   
 
Category:  General Severity:  3 - Normal
Item Group:  Build/Installation Status:  Invalid
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Thu 10 Aug 2023 01:49:31 PM UTC, comment #5: 

Withdrawing; closing as invalid.

mdate.pl's current behavior doesn't seem to be bothering anyone.  I tune out the spurious updates to the dates of groff's man pages, the same output lines update anyway due to the constantly churning git commit info.

For instance:


--- ORIGIN-MASTER/addftinfo.1.cR.txt    2023-08-10 01:31:34.259829935 -0500
+++ LOCAL-MASTER/addftinfo.1.cR.txt     2023-08-10 08:04:40.255209455 -0500
@@ -70 +70 @@
-groff 1.23.0.229‐2da1c           2 August 2023                    addftinfo(1)
+groff 1.23.0.230‐84ef8           2 August 2023                    addftinfo(1)


So changing mdate.pl as contemplated in comment #0 wouldn't even solve the above "problem".

G. Branden Robinson <gbranden>
Group administrator
Sat 28 Aug 2021 01:21:21 AM UTC, comment #4: 

It's not clear to me what to do about this, so postponing.

G. Branden Robinson <gbranden>
Group administrator
Sun 23 May 2021 07:20:57 AM UTC, comment #3: 


comment #2:

> comment #1:
> > Here's what I'm using for the time being, pretty much cribbed from StackOverflow.
>
> This unconditionally sets the date on the file, even if it has local changes more recent than what's in git.  Is that the desired behavior?


Nope.  I reckon a proper date-re-setting function/script should check that.

Having just done a nine-step one, I'll observe that a common scenario that tends to wreak havoc on file mtimes, at least for active groff developers, is "git bisect".

This is possibly something we should document in the FOR-RELEASE file.  Misleading time stamps will do the most damage in generation of a distribution archive--assuming most downstreams still work from those.

G. Branden Robinson <gbranden>
Group administrator
Sun 23 May 2021 05:10:04 AM UTC, comment #2: 

comment #1:

> Here's what I'm using for the time being, pretty much cribbed from StackOverflow.


This unconditionally sets the date on the file, even if it has local changes more recent than what's in git.  Is that the desired behavior?

Dave <barx>
Group Member
Sat 22 May 2021 09:40:45 AM UTC, comment #1: 

Here's what I'm using for the time being, pretty much cribbed from StackOverflow.

`fail()` is a function from my private shell library, but you can guess what it does.


$ type gitmtime
gitmtime is a function
gitmtime ()
{
    if [ $# -lt 1 ]; then
        fail "${FUNCNAME[0]}: need 1 or more arguments, got $#";
    else
        for F in "$@";
        do
            touch -d @0$(git log --pretty=%at -n1 -- "$F") "$F";
        done;
    fi
}


G. Branden Robinson <gbranden>
Group administrator
Sat 22 May 2021 03:18:42 AM UTC, original submission:  

Our mdate.pl script uses file modification times from the file system.  These do not necessarily match the date of the last change to the file in git, and frequently don't; for instance, if one is exploring git repo history with 'git checkout' before returning to HEAD.

This leads to spurious differences being reported in generated man pages, and possibly misleading content in our man pages--the modification time reported in the man page footer is not the time the page was last changed in any meaningful sense, but some ill-specified date probably close to the build time of the distribution archive or package.  (Admittedly, the use of the third argument to .TH as a document modification date is a convention, but one preponderantly attested in history over any alternative semantics for it, as far as I know.)

At the same time, mdate.pl is part of the distribution archive and is expected to be run from trees that are not git repositories.

So it should work in both cases.

There's more on this type of issue at <https://stackoverflow.com/questions/2458042/restore-a-files-modification-time-in-git>, including recipes for resetting the file mtime to the date of the most recent commit.

I propose that we should either (1) have mdate.pl try to determine whether it is in a git repository, and if so, to reset the mtimes before using them to determine the date; or (2) provide a separate script that a person (probably a developer working in a git tree) can invoke it before performing a build.

G. Branden Robinson <gbranden>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by gbranden (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-08-10 gbranden StatusPostponed Invalid
        Assigned toNone gbranden
        Open/ClosedOpen Closed
    2022-01-25 gbranden CategoryNone General
    2021-08-28 gbranden StatusNone Postponed

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code