CODEWITHSUNDEEP
gitgit-loggit-show
samshers
samshers

Reputation: 3690

Different time values from different git commands

I am seeing that for a particular commit, git is giving different time stamp values for different commands. 

$ git show -s --format="%ci" ee9bb
2019-09-09 17:50:43 +0530

The above command shows time value as 17:50:43

While the below commands show time value as 17:24:01

$ git show -s  ee9bb
commit ee9bb706c8fcc329fac4acf69ad6b684f1069170
Author: itsvamshers <[email protected]>
Date:   Mon Sep 9 17:24:01 2019 +0530

    fixed country null issue


$ git log ee9bb
commit ee9bb706c8fcc329fac4acf69ad6b684f1069170
Author: itsvamshers <[email protected]>
Date:   Mon Sep 9 17:24:01 2019 +0530

Could anyone explain why this is the case. And which one should I consider.

Upvotes: 0

Views: 54

Answers (1)

torek
torek

Reputation: 489638

Pay close attention to the specific details of %ci in the git log documentation (here is a direct link to %ci, but it might fail over time):

%ci
committer date, ISO 8601-like format

Now look at the %ai description:

%ai
author date, ISO 8601-like format

One uses the word committer, the other uses the word author.

There are two dates-and-time-stamps in every commit!

%ci prints the committer date and time stamp.

%ai prints the author date and time stamp.

The default git log output uses the author date, which is why %ci is showing you a different date.

Note that a bit higher up, the PRETTY FORMATS section describes keyword formats that you can get with --pretty=fuller for instance. The fuller format includes both date-and-time-stamps.

... which one should I consider

Both, or neither. Both dates can be spoofed, accidentally or intentionally. Use one or both as indications, or hints, rather than absolute guarantees.

In general, if you copy an existing commit to a new commit, Git will—at least by default—preserve the author date but set you, and now, as the committer and committer-date. Since git cherry-pick copies an existing commit, this happens for cherry-pick. Since git rebase is largely an automated series of cherry-pick operations, this tends to happen with rebase as well.

Upvotes: 2

Related Questions