Hi there,
I'm experiencing a date issue with certain commits in Git in Linus's
2.6 kernel repository.
One commit has a date from 2019, while another commit has a date from
1970. Although Git has been around for a while and seeing a Linux
commit from 2019 would be cool, I think there's something wrong here.
My questions are:
1) Is this a problem in the Git software?
2) Or is it a data corruption issue in the repository?
3) Can it be fixed and should I contact anyone to get it fixed?
I'm doing some log analysis and these two dates mess up my charts.
Steps to reproduce:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
$ git log a27ac38efd6dc6dccebfc9bcc475ab4aa5fc4a56 -1
commit a27ac38efd6dc6dccebfc9bcc475ab4aa5fc4a56
Author: Len Brown [off-list ref]
Date: Fri Apr 5 00:07:45 2019 -0500
[ACPI] fix merge error that broke CONFIG_ACPI_DEBUG=y build
Signed-off-by: Len Brown [off-list ref]
$ git log 224426f168aa4af3dcb628e6edaa824d32d60e6f -1
commit 224426f168aa4af3dcb628e6edaa824d32d60e6f
Author: Ursula Braun [off-list ref]
Date: Thu Jan 1 01:00:01 1970 +0100
qeth: remove header_ops bug
Remove qeth bug caused by commit:
[NET]: Move hardware header operations out of netdevice.
Signed-off-by: Ursula Braun [off-list ref]
Signed-off-by: Jeff Garzik [off-list ref]
Thanks,
Eirik.
On Wed, Dec 12, 2007 at 10:11:12AM +0100, Eirik Bjørsnøs wrote:
My questions are:
1) Is this a problem in the Git software?
No. Whoever made the commit probably just didn't have their clock set
right. Git doesn't generally care about the timestamp for its
operations; it just records it as a historical note.
2) Or is it a data corruption issue in the repository?
No. You can check for corruption with git-fsck, but these commits were
actually created with bad dates.
3) Can it be fixed and should I contact anyone to get it fixed?
Changing the date will change the commit id (since the id is the sha1 of
the commit contents). Which would mean rewriting all of the history that
follows it. You could do it in your own repository, but then you might
have some trouble merging with Linus later on. Linus could do it, but I
doubt he will think it is worth the trouble.
$ git log a27ac38efd6dc6dccebfc9bcc475ab4aa5fc4a56 -1
commit a27ac38efd6dc6dccebfc9bcc475ab4aa5fc4a56
Author: Len Brown [off-list ref]
Date: Fri Apr 5 00:07:45 2019 -0500
Your best guess is probably the committer information. Try this:
git log a27ac38 -1 --pretty=format:'Author: %an %ad%nCommitter: %cn %cd'
-Peff
Your best guess is probably the committer information. Try this:
Thanks Jeff, Junio,
I'll just use the committer date instead.
Being a Git newbie (only started looking at it yesterday) I'm not sure
my understanding of "author" and "committer" and how they releate to
dates is correct:
* author: Original source of the change. This person may typically
have sent a committer an email with a patch. It's the commiter's
responsibility to supply this information.
* author date: The commiter is free to specify a date for the contribution.
* committer: First committer to actually add this change to a repository
* committer date: Date of the actual commit, added by the git client
during the commit. Typically the system clock at the time of the
commit.
* A transfer of a commit across repositories (pull, push) will not
change the author, commit or date information
If I got some of this wrong, I'd be happy if someone would correct me.
Thanks,
Eirik.
Eirik Bjørsnøs wrote:
quoted
Your best guess is probably the committer information. Try this:
Thanks Jeff, Junio,
I'll just use the committer date instead.
Being a Git newbie (only started looking at it yesterday) I'm not sure
my understanding of "author" and "committer" and how they releate to
dates is correct:
They're often the same. They will end up being different if
* you cherry-pick a commit made by someone else.
("someone else" is author, you are the committer)
* you rebase a series of commit containing changes from others
("others" are the authors, you are the committer)
* you apply a patch using "git am" from someone
("someone" is the author, you are the committer)
* you "git commit --amend" a commit from someone else
("someone else" is author, you are the committer)
There are probably other cases, but those were the ones I could
think of right now.
In short, whenever a commit is modified in some way, it gets a
new committer. It might help if you think of author as "contributor"
and "committer" as "integrator", where various integrators merge
between each other. A merge obviously doesn't fiddle with commits,
so once a commit has entered an integrators repository, both author
and committer stays intact (that's not strictly true, but for the
sake of this argument, which concerns the linux kernel, it will
suffice and be mostly correct insofar as I understand the kernel
workflow).
* author: Original source of the change. This person may typically
have sent a committer an email with a patch. It's the commiter's
responsibility to supply this information.
No, it's the author's responsibility to supply this information.
Author is hardly ever changed.
* author date: The commiter is free to specify a date for the contribution.
No, the author does that too :)
* committer: First committer to actually add this change to a repository
No, committer is the person who added the commit to the repository by
some other means than merging from another repository.
* committer date: Date of the actual commit, added by the git client
during the commit. Typically the system clock at the time of the
commit.
Sort of, yes, although commits can be created by other means than
just running "git commit". The operations listed in bullets at the
top of this mail all create new commits, in the sense that they
can't have the same SHA1 as their original ones. Hence, committer
and commitdate must be updated.
* A transfer of a commit across repositories (pull, push) will not
change the author, commit or date information
True. Since neither ancestry nor content is allowed to change, the
commit will be exactly the same in the new repository as it was in
the old one.
If I got some of this wrong, I'd be happy if someone would correct me.
I think I just did. Perhaps I missed something, but I'm sure someone
will correct me if that's the case.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231