4 ms·

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.