0

GitHub’s server reports a “pushed date” associated to some commits sent to its server. It is supposed to be “[t]he datetime when this commit was pushed”. I wonder if this is true, or if there is a bug in this timestamping process.

Running the following query in the Graph explorer, I observe that the commit 4016 is reported to have been pushed at 2018-08-21T18:29:00Z, that is, before its parent of its parent, the commit 21af, reported to have been pushed at 2018-08-22T10:45:40Z. Is it possible using git to push a commit before its parent?

It is impossible to modify a commit. Thus, the commit 4016 already had its parent set, itself having already its parent set, at the time it was pushed to GitHub. (Indeed, the authoring and commit timestamps suggest so, assuming they are correct.) And I see no way of pushing a commit to a remote without also pushing its ancestors (reading the git book or the git push man page). Hence my question.

Here is the query.

{
  repository(owner: "oliviercailloux", name: "CLut") {
    object(oid: "4016d7b1b09e2a188fb99d30d1ca5b0f726a4a3d") {
      ... on Commit {
        history(first: 3) {
          totalCount
          nodes {
            oid
            message
            parents(first: 100) {
              nodes {
                oid
              }
            }
            authoredDate
            committedDate
            pushedDate
          }
        }
      }
    }
  }
}

And here is the answer.

{
  "data": {
    "repository": {
      "object": {
        "history": {
          "totalCount": 13,
          "nodes": [
            {
              "oid": "4016d7b1b09e2a188fb99d30d1ca5b0f726a4a3d",
              "message": "Intro",
              "parents": {
                "nodes": [
                  {
                    "oid": "c145866575e55309f943ad2c2b4d547b926f38d0"
                  }
                ]
              },
              "authoredDate": "2018-08-21T18:28:49Z",
              "committedDate": "2018-08-21T18:28:49Z",
              "pushedDate": "2018-08-21T18:29:00Z"
            },
            {
              "oid": "c145866575e55309f943ad2c2b4d547b926f38d0",
              "message": "Refactored into a short article",
              "parents": {
                "nodes": [
                  {
                    "oid": "21af8bffc747eaee04217b9c8bb9e3e4a3a6293d"
                  }
                ]
              },
              "authoredDate": "2018-08-21T18:25:52Z",
              "committedDate": "2018-08-21T18:25:52Z",
              "pushedDate": null
            },
            {
              "oid": "21af8bffc747eaee04217b9c8bb9e3e4a3a6293d",
              "message": "Minor (wording and a ref)",
              "parents": {
                "nodes": [
                  {
                    "oid": "f63a7c3a01123b266274728179c9cd46b41b69a5"
                  }
                ]
              },
              "authoredDate": "2018-08-21T14:35:14Z",
              "committedDate": "2018-08-21T14:35:14Z",
              "pushedDate": "2018-08-22T10:45:40Z"
            }
          ]
        }
      }
    }
  }
} 

Here is the relevant bit of history:

21af [reported pushed at 22 aug 10h45m40s; authored at 21 aug 14h35m14s] <- c145 [authored 21 aug 18h25m52s] <- 4016 [reported pushed at 21 aug 18h29m00; authored at 21 aug 18h28m49s]

Note that my question differs from this one, as my question is about the pushed dates timestamps set by the GitHub server, not about the commit and author dates stored in the commits.

When asked to the GitHub support, they simply confirmed to me that the observed pushedDate values conform to their internal data in the case of this repository, so they consider it not a bug.

Background (Taken from here.)

The reason I am interested in timestamps provided by GitHub is that I use GitHub as a trusted time source. The commits themselves contain timestamps, but the client can put whatever time is desired there. I need to know the real time commits were sent to GitHub to grade student works and penalize them if they are late.

I know that GitHub classroom (which I am a happy user of) provides some timestamping option, but it does not permit to get a timestamp to multiple commits as I would like to have.

I am also aware that GitHub will not provide events older than three months through its API. That’s fine with me. My goal is to retrieve timestamps of recent events (meaning, say, one month old or more recent).

Olivier Cailloux
  • 977
  • 9
  • 24
  • Ask the developer. Sounds like they did a rebase. – EncryptedWatermelon Nov 08 '19 at 19:24
  • 1
    Does this answer your question? [Git: parent commit is younger than descendant?](https://stackoverflow.com/questions/12934044/git-parent-commit-is-younger-than-descendant) – EncryptedWatermelon Nov 08 '19 at 19:29
  • 1
    I don't know where GitHub gets these "pushedDate" fields. They're not part of the commits. It seems likely that GitHub made up two dates and mixed them in (and/or up), in a way that's not reflective of some sort of underlying reality. Note how commit `c145866575e55309f943ad2c2b4d547b926f38d0` has no pushedDate. – torek Nov 08 '19 at 22:31
  • @EncryptedWatermelon no, it doesn’t. My question refers to pushed date timestamps, which are set by the GitHub server. Also, I have already asked the developer (it’s me), and he doesn’t remember exactly what he did. In any case, I am interested to know in general how such a situation is possible (if it is). – Olivier Cailloux Nov 09 '19 at 07:55
  • @torek Precisely, I would like to know if these pushed dates may possibly reflect truthfully the dates at which the commits arrived on their server. If not, I would like to have some convincing explanation that a commit can’t ever be pushed before its parent in git (if that’s true). I have updated the question to clarify the context. – Olivier Cailloux Nov 09 '19 at 08:09
  • Without information from GitHub themselves, all we can do is guess where these came from. But except in shallow repositories you're not allowed to have a commit in a repository without also having all of its immediate parents, and applying transitive closure to that gives you the property that having the last commit implies that you have all of the earlier commits. – torek Nov 09 '19 at 18:30
  • The new promisor pack experimental stuff in Git changes this equation: if you trust some other Git repository sufficiently, you're now allowed to take a sort of "object reservation" without taking the actual object itself. You then fill in the reservation later, on demand, from whoever promised to deliver you the object upon demand. We could guess that GitHub are working on this feature internally, and experimenting with promisor packs with this kind of result. – torek Nov 09 '19 at 18:33
  • @torek An answer that is correct except for experimental stuff would be enough for my needs. The information that “you're not allowed to have a commit in a repository without also having all of its immediate parents” is exactly what is needed to answer my question, I just need to know the source for that claim. I am looking for an authoritative source about classical git protocols, nothing GitHub specific. – Olivier Cailloux Nov 10 '19 at 23:49

0 Answers0