Consequences of commit time being in the future

Question

I've accidently committed & pushed a change to the remote while my device date time was set to few days in the future(i.e. date is set to 23rd instead of 21st).

I've referred this which will solve my problem, but advised not to perform it due to the force push.

So my question is will keeping the wrong date and time of a commit adversely effect the Git repo (Local & Remote). I use "Git Lab" as my remote repository provider.

Generally speaking, no. Some poorly-written tooling that assumes a strictly chronological order might get confused, but in Git all that matters is the `parent` commit references. That said, git was designed around chronologically re-ordered commits anyway - that's how you `rebase`. — Dai, Dec 21 '20 at 04:40
@Dai according to what I understand you're saying that its not a problem as long as a `rebase` is not performed — Randika Perera, Dec 21 '20 at 04:48
No, I'm saying it's not a problem at all because a `rebase` in git is a very common operation. — Dai, Dec 21 '20 at 04:51

Daemon Painter · Accepted Answer · 2020-12-21T09:21:31.633

So my question is will keeping the wrong date and time of a commit adversely effect the Git repo (Local & Remote). I use "Git Lab" as my remote repository provider.

The answer is: "it depends". From a git perspective, it does not: the date is recorded as metadata and the commit order is provided based on parent/child relationship. Please see this answer for further study.

However, if you employ CI scripts or care deeply for the actual history of the repository, recording wrong metadata is bad in a broad sense. It can be fixed.

On a side note, you may do a lot of stuff with metadata, such as, but not limited to, creating commits in the past.

Committing

The final creation of a Git commit object is usually done by git-commit-tree, which uses these environment variables as its primary source of information, falling back to configuration values only if these aren’t present.

GIT_AUTHOR_NAME is the human-readable name in the “author” field.

GIT_AUTHOR_EMAIL is the email for the “author” field.

GIT_AUTHOR_DATE is the timestamp used for the “author” field.

GIT_COMMITTER_NAME sets the human name for the “committer” field.

GIT_COMMITTER_EMAIL is the email address for the “committer” field.

GIT_COMMITTER_DATE is used for the timestamp in the “committer” field.

EMAIL is the fallback email address in case the user.email configuration value isn’t set. If this isn’t set, Git falls back to the system user and host names. source

This is another very nice reference to understand git internals:

Let us consider the hashes of these objects for a bit. Let’s say I wrote the string git is awesome! and created a blob from it. You did the same on your system. Would we have the same hash?

The answer is — Yes. Since the blobs consist of the same data, they’ll have the same SHA-1 values.

What if I made a tree that references the blob of git is awesome!, and gave it a specific name and metadata, and you did exactly the same on your system. Would we have the same hash?

Again, yes. Since the trees objects are the same, they would have the same hash.

What if I created a commit of that tree with the commit message Hello, and you did the same on your system. Would we have the same hash?

In this case, the answer is — No. Even though our commit objects refer to the same tree, they have different commit details — time, committer etc. source

score 1 · Answer 2 · answered Dec 21 '20 at 08:06

but advised not to perform it due to the force push.

Any rebase would necessitate a force push for the rebased branch to be published.

But that is only an issue is this is done on a public branch where multiple collaborators are working on.

If it is your own working/topic branch, you can rebase/force push as many times as you want.
This is actually done before a pull request, to ensure an easy merge by the maintainer (or the maintainer can trigger the rebase themselves).

Consequences of commit time being in the future

2 Answers2

Committing