如何从GitHub仓库中找到最新的clone / fetch / pull？

Question

Does GitHub make the time of a repo's latest pull/fetch/clone available (at least to those with write-access to the repo)?

The interest in this information, of course, comes from wanting to gauge how safe it would be to do a git push -f on the repo that would essentially overwrite the last few commits: if no pull/fetch/clone has happened since the earliest commit-to-be-overwritten was pushed to GitHub, then the overwrite may be OK...

---

Perhaps an example will clarify my question. For simplicity, let's assume that there's only one local branch ( master ) and one remote branch ( origin/master ). (IOW, the remote repo has only one branch, and I am tracking it with our only local branch.)

First consider a completely local scenario: I make a commit, and shortly after realize that there was a problem with this commit. In this case, I just overwrite this commit with the correct one using git commit --amend ... .

Now imagine exactly the same scenario, with the difference that, before noticing the problem with the commit, I push the faulty commit to the remote (GitHub) repo.

If I am the only user of this repo, then I can simply overwrite the commit locally as before, and then use git push -f ... to overwrite the faulty commit in the remote (GitHub) repo.

If, however, I am not the only user of this repo, the above procedure is problematic, because a different user could have cloned or fetched from the remote (GitHub) repo at some point after I pushed the faulty commit, but before I overwrote the faulty commit in the remote repo.

One way to minimize this possibility is to examine a record of all the pull, fetch, and clone operations performed on the remote repo since the time I pushed the faulty commit to it. If this record shows at least one of such operations, then it would mean that we have precisely the problematic scenario described in the previous paragraph.

If, on the other hand, the record shows no such operation, then there is still some hope that I could overwrite the faulty commit in the remote repo without incurring in the problematic scenario described earlier. (Of course, this is a race condition, so there's no 100% guarantee.)

All this, however, is predicated on the availability of such record of pull, fetch, and clone operations on the remote repo. I'm question is whether GitHub makes such record available, at least to those with write-access to the repo.

Answer 1

The GitHub V3 API does return, for a user's repositories :

...
    "pushed_at": "2011-01-26T19:06:43Z",
    "created_at": "2011-01-26T19:01:12Z",
    "updated_at": "2011-01-26T19:14:43Z"
  }

The " pushed_at " field might be the time of the last commit, but not necessarily the last commit on the branch on which you are about to push --force .

However, there is no record of the latest pull, fetch of clone , especially considering that an upstream repo has no idea of how many downstream repos are accessing it and when.

See " Definition of “downstream” and “upstream” ".

GitHub could record those information: it is an upstream repo, but manages its own infrastructure and access mechanism, so yes, it could record said access.
But I don't believe that kind of information is available at all for users to see.

Answer 2

Because in your issue you posted the real intent as being:

..comes from wanting to gauge how safe it would be to do a git push -f...

I think a change to your workflow would make life much easier. I'd suggest doing the following:

Don't commit non-trivial changes directly to master (basically anything that you might want to change later). Once a change has been landed in master it should never ever be touched. Here is an example:

# assuming starting on master branch
git checkout -b new_cool_idea
# commit a few things
git push origin new_cool_idea
# realize there was a bug preventing you from finishing the
# implementation of new_cool_idea
git checkout -b cool_idea_bug_fix master
# commit the bug fix
# if you have any reviewers, push to remote
git push origin cool_idea_bug_fix
# when bug fix is all good, cleanup and finish new_cool_idea
git checkout master
git merge cool_idea_bug_fix
git branch -d cool_idea_bug_fix
git push origin :cool_idea_bug_fix
git checkout new_cool_idea
git rebase master
# may possibly have conflicts, go ahead and resolve
# now finish implementing new_cool_idea
# if you only want to update one remote branch add <remote> <branch>
# otherwise all remotes will be updated
git push -f <remote> <branch>

This should help prevent needing to --rebase on master . Which again shouldn't ever happen. There is a more advanced technique that you might want to use. Say the bug_fix branch takes a little while to fix, but you also want continue developing new_idea while testing out the bug fix. So say we start with the following:

o-----o-----o             master
      |      \
      |       o-----o     bug_fix
       \
        o-----o           cool_idea

So what we want is to apply the changes from cool_idea on top of bug_fix so we can work with them in tandem. Here's how you'd do that:

git checkout cool_idea
git rebase --onto bug_fix master cool_idea

Then you're history would look like the following:

o-----o-----o                   master
             \
              o-----o           bug_fix
                     \
                      o-----o   cool_idea

If you would really consider using this method then I'll write up the steps for cleanup if you need to add a commit to or --rebase the branch bug_fix .