CODEWITHSUNDEEP
git
Polymerase
Polymerase

Reputation: 6791

How could a commit on remote survive a forced push?

I leak a credentials on a file in my feature branch. A reviewer caught the mistake, showing the hash commit, lets call it a6859b6, when the bad info was introduced and asked me to safely remove. I edited the file, squashed all commits in my branch and forced push.

Then the PR got approved, and merged into master. My branch is deleted on remote and locally. The commit log of master doesn't show any presence of the "bad" commit a6859b6

Surprisingly, querying remote on the exact commit hash https://gitlab.com/blabla/-/commit/a6859b6 still show the offending code.

Is it by design? How do we call this kind of "orphan" commits? What does git do with these and is it possible to purge a specific orphan commit?

EDIT: GitLab answered to my support ticket

Upvotes: 1

Views: 113

Answers (1)

dan1st
dan1st

Reputation: 16373

Is it by design?

Yes, git does not instantly delete objects once they are not referenced. This may be done eventually by the GC (git gc). Not instantly removing such references makes it easy for you to recover lost data using git reflog (as long as you have added/committed the data previously).

How do we call this kind of "orphan" commits?

You can call them loose objects/commit. This name is also used in the docs.

What does git do with these and is it possible to purge a specific orphan commit?

Git may eventually decide to clean these up (depending on gc.auto). This can also be done manually by running git gc --prune=now in the repository where you want to remove it (you need shell access). If you have a long reference chain referencing the object that is not referenced any more, you may want to add --aggressive: git gc --aggressive --prune=now.

If you don't have direct access, you could mirror the repository, run git gc --prune=now, delete the remote repository, recreate an empty repository and push everything from your local mirror.

Anyways, I would strongly recommend you to change/invalidate the leaked credentials as soon as possible as people could already have downloaded your commit (and the reviewer has seen those, too). When you are sure that your leaked credentials are not valid anywhere, you don't need to worry about unreferenced commits.

Upvotes: 3

Related Questions