Questions on history protection for Git repositories in TeamForge.
- What is history protection?
- History rewrites are non-fast-forward updates of remote refs
and associated objects. History rewrites happen when a branch in a remote
repository gets deleted, previously pushed commits get amended/tree filtered and
forcefully re-pushed, or a remote branch/tag is pointed to an entirely different
commit history. For more information, see
History Protection.
- Is it possible to turn on history protection for all Git repositories hosted on a Git integration server? If yes,
how?
- Yes, a user with file system access to the Unix machine where the Git integration is hosted can turn on
history protection. First set the property forceHistoryProtection =
true in
/opt/collabnet/gerrit/etc/gerrit.config in the
[gerrit] section. Then restart the
gerrit service by running $ service gerrit
restart on a shell.
With
TeamForge 7.1, do the following:
- I've enabled Protect History for my TeamForge project's Git repository. Will this be
effective immediately?
- To enable history protection immediately, a TeamForge user with the Source Code Admin
permission must do this right after enabling Protect
History: temporarily remove any user with a project role with
any SCM permission, and then add that user back. This will trigger an immediate
sync after which history will be protected for the Git repository. Otherwise, history
protection will be enabled after a periodical sync.
- Can I turn off history protection for any particular Git repository when it is enabled
server-wide?
- No, when history protection is enabled server-wide for the Git integration server, it cannot be
turned off for a particular Git
repository.
- Where can I see the backup branches generated by history protection?
- Backup branches are generated based on the type of History Rewrite. For a remote
branch that is deleted, this is under refs/delete. For a
non-fast-forward push, this is under refs/rewrite with the
branch name containing the timestamp, original branch and the user who rewrote
history, for example,
refs/delete/20121112042512-test--david.
- Who can resurrect or permanently delete backup branches?
- A user who is a member of the Gerrit Administrator group can resurrect or permanently delete backup branches. By
default, the TeamForge site
administrator whose credentials are used for running the post-installation
script is part of the Gerrit
Administrator group.
- Who can see backup branches?
- By default, a TeamForge user with SCM
View (or more) permission can see all backup branches by executing git
fetch && git ls-remote origin. In Gerrit, the user must be part of a group
which has at least read access for refs/delete and
refs/rewrite for the given Gerrit project (TeamForge
Git repository).
- Are the backup branches under refs/rewrite and
refs/delete protected from Git garbage collection which removes
unreferenced objects?
- Yes, objects in backup branches under refs/rewrite and
refs/deleted are referenced and cannot be cleaned up by
Git's garbage collection.
- Do backup branches take up a lot of disk space on the Git server?
- The backup branches on the Git
server are mainly Git objects that are compressed deltas of original
file versions. Git regularly
compresses these objects to save disk space.
- What is the difference between Git
reflog and History Protect?
- In Git, reflog
records all activity on a branch, while History Protect only reports deleted
branches/tags and history rewrites (non-fast-forward pushes) For details of all
the differences, see Git reflog vs TeamForge–Git integration History Protect.