Uploaded image for project: 'Bitbucket Data Center'
  1. Bitbucket Data Center
  2. BSERV-9018

Provide an option to enable reflogs on the Git repos

    XMLWordPrintable

Details

    • Suggestion
    • Resolution: Duplicate
    • None
    • None
    • None
    • We collect Bitbucket feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

    Description

      • For your specific use case, I thought I'd shed some light on the timing aspect you mentioned (i.e. 1 month after you realised that a force push had been done):
        • There are a few things that you should consider when having reflogs enabled and how this can effectively help you in such scenario:
          • When you force push, you may (not necessarily but very likely) create a loose object - i.e. not reachable from some reference
        • Assuming that you will create a loose (or unreferenced) object by performing a force push, there are a few things you should consider:
          • you should know that a loose object will be pruned when git gc is run unless it is registered in the reflog;
            • You can refer to the git gc man page where the gc.pruneExpire default value is specifically relevant to you as you're could be generating a loose object with a force push:

              The optional configuration variable gc.pruneExpire controls how old the unreferenced loose objects have to be before they are pruned. The default is "2 weeks ago".
              (...)

              Notes

              git gc tries very hard to be safe about the garbage it collects. In particular, it will keep not only objects referenced by your current set of branches and tags, but also objects referenced by the index, remote-tracking branches, refs saved by git filter-branch in refs/original/, or reflogs (which may reference commits in branches that were later amended or rewound).

          • Notice that from the git reflog man page, reflog entries for unreferenced objects are also expired at some stage:

            --expire-unreachable=<time>
            Prune entries older than <time> that are not reachable from the current tip of the branch. If this option is not specified, the expiration time is taken from the configuration setting gc.reflogExpireUnreachable, which in turn defaults to 30 days. --expire-unreachable=all prunes unreachable entries regardless of their age; --expire-unreachable=never turns off early pruning of unreachable entries (but see --expire).

        • Therefore, if you were to keep reflogs for the default amount of time, you would be insured for at least 1 month period before a git gc is run.

      In light of all that, we provide a repository hook shipped with Bitbucket that stops force pushes from happening. You would have to enable it per repository, though. Please have a look at Using repository hooks. Another (more flexible) alternative is the branch permissions we provide. You could use that to protect branches in various different ways. Please refer to:

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              tbomfim ThiagoBomfim (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: