1

I'm trying to find the last modification timestamp of a file in a Git repository. I understand that Git doesn't preserve timestamps for files under its control, so some trickery is due.

For purposes of discussion, consider the following directory structure:

/ ├─ catalog.xml ├─+ doc │ └─ notes.md └─+ src ├─ index.xhtml └─ style.css 

What I'm trying to accomplish is this: Whenever changes are about to be committed,

  • if any file under the src directory was modified,
    • find the most recent (filesystem) modification timestamp,
    • update the catalog.xml manifest using that timestamp.

How can this be done?

If a potential solution requires scripting, I'm looking for something that works on Windows, using batch and/or PowerShell as the scripting environment.


Additional details:

As far as I understand, Git doesn't record modification timestamps for individual files. While commit objects are timestamped, this isn't useful for my needs. Are per-file modification timestamps perhaps stored in the local "index"?

Either way, I will have to tap into Git's processing pipeline. A pre-commit hook seems like a reasonable callback to gather the information and perform the update. This isn't ideal, however, as it may result in changing a file. Could a "clean" filter be used for this instead?

17
  • 1
    As I understand, you mean the file modification time, not the times of any git events, right? You are right, this is not what git does. I have a different question: why do you think the feature you want can help development? At first glance, it would be a kind of technology misuse. Nothing should depend on such a poorly controlled detail as the time of file modification. Commented yesterday
  • catalog.xml could end up being massive. Also, how will you handle multiple clones of the same repo? You'll likely end up with large conflicts. Commented yesterday
  • 1
    @SergeyAKryukov "Nothing should depend on such a poorly controlled detail as the time of file modification." - Every build system depends on this "poorly controlled detail". This is the rationale behind Git's design choice to not record (and restore) file modification timestamps. Commented yesterday
  • 1
    @IInspectable — I'm talking in concrete terms here, not on all abstract details in the world. Perhaps I'm mussing something. Are you the one who could clearly explain the possible merits of such a feature? — Thank you! Commented yesterday
  • 1
    @IInspectable Continue… You pushed the branch from H1 to S. Someone tried to pull updates from S to H2 and failed because local and remote catalog.xml have two different changes for the same file that couldn't be auto-merged. For every file changed at both H1 and H2 there will be a conflict. When you resolve the conflicts you find that catalog.xml lies because files in src changed by merge but catalog.xml doesn't get it. Commented yesterday

0

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.