magit-log: ability to change commit timestamp format

[razzmatazz]

In Magit log buffer commits (one per line) are shown with relative date. This is nice for recent commits, but makes little sense for older changes. In particular, this makes it annoyingly hard to relate commit dates to specific date, e.g. to find answer to question "which change might have broken the release on 3rd of April?".

Is it possible to somehow change the way commit dates are shown? I only found magit-duration-spec, but that's not exactly what I need.

• The text above is from http://emacs.stackexchange.com/questions/14483/magit-log-dates where it was suggested for the submitter to create a feature request for this. I could not find on magit issue tracker on github here so I went on to create it myself.

[tarsius]

I've started work on this but it makes some ugly code even uglier and the doc-string of magit-log-margin-spec even more so. Too many implementation details are leaking into that variable, making it rather hard to customize it properly.

The %ar and %cr formats are not supported, for that the existing elisp implementation has to be used. %ad and %cd are also not supported, meaning that the date part of the margin has to be at least 25 characters wide. Together with the name part the total margin width should not be much less than 42 characters wide, which doesn't leave much room for the commit hash, graph and message. So I am wondering whether this would actually end up being used much.

I will have to investigate whether the use of %ad together with --date= allows using shorter date strings, which don't lose any information except maybe the timezone. The timezone cannot just be removed without the date/time being adjusted accordingly to UTC or local time. I don't know if Git can do that or whether we have to translate (which would be rather nasty).

An alternative would be to always use %at/%ct and do all the time formatting in Emacs.

I substituted an elisp implementation for Git's relative date formatting because we want something with a predictable and short width, e.g. "13 months". But Git would say "1 year and 1 month" ago in that case, which also is to wide. I am however wondering whether it would not have been better to translate Git's output into our preferred format instead. I will have to look for the commit message where I explain why I decided otherwise. If we did post-process Git's relative output, then we would have to make sure it never prints more than two time units.

The main reason Magit uses relative dates is that someone a long time ago contributed it that way. I had to essentially re-implement that because the original implementation was extremely messy and inefficient. Maintaining the original feature set but doing it right was already a lot of work. So I sticked to relative dates and did not invest any more time also implementing absolute dates. Going with absolute dates would have been much easier but would also have caused protests by those already used to the relative dates.

Absolute dates don't work right now for reflogs.

Anyway the implementation is at https://github.com/magit/magit/compare/jb/log-margin-format?expand=1, but it is unlikely that this or something similar will be merged anytime soon. I will work on this again eventually, but cannot say when.

[tarsius]

Implemented in 186c3d6ccbca78386cb0faa69164b3396bb38ae6. As expected that was quite a bit of work. The core change actually was easier than expected - just throw away all the crap - but making it easy to customize and writing documentation was quite a bit of work.

[ylluminarious]

For anyone looking for the specific customization variable mentioned by @razzmatazz and in the Stack Exchange post he links to: it's magit-log-margin