4 ms·

Not related to private repositories; but GitHub also keeps logs about commits in the "Activity Graph" if these commits do not exist anymore. For example, clear

Not related to private repositories; but GitHub also keeps logs about commits in the "Activity Graph" if these commits do not exist anymore. For example, clearing the full reflog of a repository and then either force pushing over or deleting the remote repository (then pushing it again under a different name) will keep the activity attribution, in the second case it might even attribute the commits to the new remote (404ing when clicking the "Created x commits in y repositories"). Good for team workflows and pull requests, but annoying for public repositories with intentionally rewritten history.

semiquaver 3y ago
Reflog is data local to a git node, not part of the repository. In particular reflogs are never transmitted between remotes. so “clearing the reflog” (presumably of your local machine) has nothing to do with removing any data at GitHub. You need to contact support for that which the docs advise you to do if you’ve force pushed over something you want to be fully deleted.
- moritzwarhier 3y ago
  Thank you, today I learned
  - semiquaver 3y ago
    No problem. One easy way to gain confidence that data has actually been wiped instead of just obscured is to use one of the gitrevisions [1] specifiers that sources data from the reflog. For example, master@{yesterday} resolves to whatever the reflog thinks the master branch was pointing to 24 hours ago. There are a bunch of places in the GitHub API and UI that look like they only accept a branch or commit OID but actually accept a revision specifier. So e.g https://github.com/torvalds/linux/tree/master@{yesterday} lets you peek into the reflog for the master branch on torvalds/linux. [1] man 7 gitrevisions
    - moritzwarhier 3y ago
      Thank you very much! Apart from the misconception, I worded my initial post in an inprecise way. I did not know wether or not the reflog relates to what's pushed to the remote. I just had the expectation that an empty git log as well as git reflog output would mean that no objects exist except for what represents the tree of the current HEAD. Still haven't tried the revision specifiers on a repository that I expected to be wiped, but will do that. I need to read more docs about git plumbing and the .git folder.
      - semiquaver 3y ago
        > I just had the expectation that an empty git log as well as git reflog output would mean that no objects exist except for what represents the tree of the current HEAD. It’s a pretty common expectation but the nature of git’s object model means that generally it’s not true for any git provider. You should assume that data pushed to any git remote will live forever unless you both force push away all references to the data and GC all remotes (which for GitHub means contacting support IIRC)
        moritzwarhier 3y ago
        Thanks again for your thoughtful responses.

semiquaver 3y ago

Reflog is data local to a git node, not part of the repository. In particular reflogs are never transmitted between remotes. so “clearing the reflog” (presumably of your local machine) has nothing to do with removing any data at GitHub. You need to contact support for that which the docs advise you to do if you’ve force pushed over something you want to be fully deleted.

moritzwarhier 3y ago
Thank you, today I learned
- semiquaver 3y ago
  No problem. One easy way to gain confidence that data has actually been wiped instead of just obscured is to use one of the gitrevisions [1] specifiers that sources data from the reflog. For example, master@{yesterday} resolves to whatever the reflog thinks the master branch was pointing to 24 hours ago. There are a bunch of places in the GitHub API and UI that look like they only accept a branch or commit OID but actually accept a revision specifier. So e.g https://github.com/torvalds/linux/tree/master@{yesterday} lets you peek into the reflog for the master branch on torvalds/linux. [1] man 7 gitrevisions
  - moritzwarhier 3y ago
    Thank you very much! Apart from the misconception, I worded my initial post in an inprecise way. I did not know wether or not the reflog relates to what's pushed to the remote. I just had the expectation that an empty git log as well as git reflog output would mean that no objects exist except for what represents the tree of the current HEAD. Still haven't tried the revision specifiers on a repository that I expected to be wiped, but will do that. I need to read more docs about git plumbing and the .git folder.
    - semiquaver 3y ago
      > I just had the expectation that an empty git log as well as git reflog output would mean that no objects exist except for what represents the tree of the current HEAD. It’s a pretty common expectation but the nature of git’s object model means that generally it’s not true for any git provider. You should assume that data pushed to any git remote will live forever unless you both force push away all references to the data and GC all remotes (which for GitHub means contacting support IIRC)
      - moritzwarhier 3y ago
        Thanks again for your thoughtful responses.