How long does git not allow interruptions?

Question

Suppose I create a branch in my local repository called feature1 based on master and add one or two commits. Then I go back to master and decide that feature1 not going to do this and delete the branch.

I assume that the branch is basically a "pointer" to a specific commit object.

Now to the current issues.

• Is the assumption above the correct, perhaps in a simplified sense?
• How long do commit objects still exist on the file system (so that I can do git checkout SHA1-HERE later)? Is there some kind of "retention policy" that removes commits that are not part of any history or branch tag (not sure if the correct terminology is used here ...)?
• Can any of the above be dependent on git server implementation (gitosis, github, etc.)?
• If objects are stored permanently and will not be automatically cleaned after some time / event, does this mean that setting git receive.denyNonFastForwards as a measure to prevent data loss does not make sense?

The reason for this question: I am currently working on a project that has receive.denyNonFastForwards , based on which it avoids losing any perfect work (I suspect receive.denyDeletes also applied). I want to make sure that there is no better way to save earned but indelible work, as well as clean old branches to avoid clutter.

Answer 1

Default value: 90 days:

 gc.reflogexpire gc.<pattern>.reflogexpire 

git reflog expire deletes log entries older than this time; default is 90 days. If " <pattern> " (for example, " refs/stash ") is in the middle, the parameter applies only to refs that match <pattern> .

So:

• Yes
• 90 days
• no (you can really contact GitHub support to ask them and restore the deleted push branch)
• "save earned but not connected": you can click it on the dedicated dev branch or on the dedicated upstream repository (just for you).