0

Desired Solution: I want magit to make a commit with a datetime set to the time that I "create" the commit, not the time that I start the commit "creation" flow.

Background:

So committing in magit in general follows these steps:

  1. S Stages all files.
  2. c c Initiates a commit, then write the message in the "commit buffer".
  3. C-c C-c to actually create the commit.

The thing that surprises me is that the datetime of the created commit is actually the datetime that I pressed c c, NOT the time that I pressed C-c C-c. I find this very annoying as I am trying to be better about writing more detailed commits (often spending a few minutes on them). The date of the commit does not reflect when I actually created the commit, it instead reflects when I started the commit.

Details:

Why do I care about being off by a few minutes? Because I am recording videos as I work and would like to slice them at the commit points. However, the commit points are all a few minutes before the actual commit was made in the video. This is kind of annoying.

Improve this question
5
  • 1
    Given that editing the transient suffix to overide author date won't make a difference for you, setting up GIT_COMMITTER_DATE and/or GIT_AUTHOR_DATEenvironment variables is the only way I know. I'd use git-commit-setup-hook to set it up to current value. This isn't perfect and reasons are explained in the manual, but less messy than automatically amend each commit. – Muihlinn May 5 '20 at 7:55
  • 1
    Please note that this is not "Magit's behaviour" -- the issue has nothing to do with Magit. It is no different if you run git commit from the command line -- git will invoke whatever editor you have configured, and ultimately the commit timestamp will be the point at which you invoked the command, not the point at which you finished editing the message. Magit simply arranges (via its with-editor magic) that the editor invoked by git will be the Emacs instance you're using at the time; but it's still just calling git commit, and the commit timestamp is entirely subject to that. – phils May 5 '20 at 11:52
  • 1
    You could, of course, log a bug report for git, if you feel that behaviour is wrong. – phils May 5 '20 at 23:47
  • Thank you for clarifying that this is Git behavior and not Magit behavior. I always either use Magit or use git commit -m "<message>" and so thought it was something being introduced by Magit. I do find the default behavior a bit funny. It is strange that the recorded "time" of something is actually before the commit finalized. However, I also recognize that the hash is partially time dependent, and how could you build the hash if you can't "freeze" the commit time? Seems a bit odd, but at the same time, I get it. Anyway, thank you for clarifying. – Stephen Cagle May 14 '20 at 4:08
  • Seeing as how the commit message is also a part of the hashed data, I don't think that's the reason. It seems like a fair question to ask upstream. – phils May 14 '20 at 9:05
2

magit-commit-reshelve on c n is intended for that use-case. [Well not your very specific use-case in particular, more the general idea.] It is disabled by default; see Enabling and Disabling Suffixes.

A multi-commit variant exists as well; magit-reshelve-since on r t.

Improve this answer
1

My solution to the problem was to register a post-commit hook that "nudged" the commit & author date. It has the possibility of running endlessly, but on my machine it only runs once or twice. Anyway, it does set the commit time to be immediately after I submit my commit message.

#!/bin/sh

STR1=$(git log -1 --format=%cd --date=iso | sed 's/[^0-9]*//g')
STR2=$(date --iso-8601=seconds | sed 's/[^0-9]*//g')
if [ "$STR1" != "$STR2" ]; then
    sleep 0.1s
    git commit --amend --no-edit --date=now
fi

Source Code Here

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.