Package: gitprivacy
git-privacy: Keep your coding hours privategit-privacyredacts author and committer dates to keep your coding hours more
private. You can choose the level of redaction: only remove minutes and seconds
from your dates or even hide day or month.
The original dates are encrypted and stored in the commit message in case you
might need them.Installationgit-privacycan be easily installed via pip:$ pip3 install gitprivacyNote:git-privacyrequires Python version 3.6 or later and Git version 2.22.0 or later.Getting StartedYou can either setupgit-privacyseparately for selected Git repositories or
globally so that each new Git repo automatically usesgit-privacyfrom the
beginning.To setupgit-privacyfor asingle Git repositorydo the following:Initialisegit-privacy, which sets the necessary hooks.$ git-privacy initSet a redaction pattern from the following options:M: Sets the month to Januaryd: Sets the day to the first day of the monthh: Sets the hour to midnightm: Sets the minute to zero (full hour)s: Sets the seconds to zero (full minute)$ git config privacy.pattern <pattern>For example:$ git config privacy.pattern hmsSet an encryption key if you want to preserve the original timestamps in
encrypted form in the commit message.
If no key is set, only the reduced timestamp will remain.$ git-privacy keys --initFor more information about managing encryption keys seegit-privacy keys -h.Use Git as normal ;-)To setupgit-privacyglobally for all new repositoriesdo the following:Initialisegit-privacyto set the necessary hooks globally (in a Git
template directory).$ git-privacy init --globalSet a global redaction pattern from the following options:M: Sets the month to Januaryd: Sets the day to the first day of the monthh: Sets the hour to midnightm: Sets the minute to zero (full hour)s: Sets the seconds to zero (full minute)$ git config --global privacy.pattern <pattern>For example:$ git config --global privacy.pattern hmsUse Git to init or clone repos as usual andgit-privacywill redact
timestamps for you :-)Per individual repo:Set an encryption key if you want to preserve the original timestamps in
encrypted form in the commit message.
If no key is set, only the reduced timestamp will remain.$ git-privacy keys --initFor more information about managing encryption keys seegit-privacy keys -h.For an overview of further features and options read the following sections.UsageRedaction of New CommitsNew commits are automatically redacted ifgit-privacyis initialised in a repo.
This is achieved via a post-commit hook.If you want to manually redact the last commit, run:$ git-privacy redate --only-headBulk Re-dating of CommitsTo redact and redate all commits of the currently active branch run:$ git-privacy redateWarning: This will likely rewrite the Git history and might lead to
diverging commit histories.
SeeA Warning about Git History Rewriting.Note:git-privacywarns you if you attempt to redate commits that have
already been pushed to a remote. However, you can force it to do so anyway.Re-dating of Commits from a StartpointYou can also limit the redate to all commits that succeed a given startpoint:$ git-privacy redate <startpoint>This will redate all commits in the range<startpoint>..HEAD(see git rev-list for syntax details).For example, you can use this to redate all commits of a branch since it has been branched off frommasterby invoking:$ git-privacy redate masterView Unredacted DatesTo view the unredacted commit dates,git-privacyoffers a git-log-like listing:$ git-privacy logNote: Unredacted dates are only preserved if you set an encryption key
which allowsgit-privacyto store the encrypted dates in the commit
message.Redate after Rebases and other RewritesSome Git operations likegit rebaseorgit commit --amendrewrite existing
commits. Consequently, a new commit date is set for those commit.git-privacytakes notice of such rewrites via apost-rewritehook, logs
them and alerts you that unredated commit dates have been introduced to the
repository, as shown in the following example:$ git rebase -i HEAD~2
Rebasing (1/2)
Rebasing (2/2)
A rewrite may have inserted unredacted committer dates.
To apply date redaction on these dates run

git-privacy redate-rewrites

Warning: This alters your Git history.
Successfully rebased and updated refs/heads/master.To redate the rewritten commits run, as mentioned:$ git-privacy redate-rewritesWarning: This will rewrite the Git history again and can lead to
diverging commit histories.
SeeA Warning about Git History Rewriting.Time Zone Change WarningsGit commit dates include your current system time zone. These time zones might
leak information about your travel activities.git-privacywarns you about any changes in your system time zone since your last commit.
By default, this is just a warning.
You can setgit-privacyto prevent commits with changed time zone by running$ git-privacy init --timezone-change=abortor by setting theprivacy.ignoreTimezoneswitch in the Git config toFalse.Email Address RedactionImagine you want to publish a repository which contains some contributor's private email addresses.git-privacymakes it easy to redact such addresses:$ git-privacy redact-email john@example.com paul@example.netYou can also specify individual substitutes:$ git-privacy redact-email john@example.com:john@bigfirm.invalidOr, you can use your GitHub username and GitHub'snoreply addressesto still have your commit associated to your account and get credit:$ git-privacy redact-email -g john@example.com:johnConfiguration Optionsgit-privacytakes the following configuration options viagit-config.privacy.ignoreTimezoneIf true,git-privacywill only warn you if your timezone has changed since
your last commit. If false, it will abort the commit. Default is true.Note: This requires that thepre-commithook is set bygit-privacy init.privacy.limitIf set, redacted timestamps will be rounded towards the given interval.
The format ishh-hhwherehhis a value between 0 and 24.Example:limit = 9-17means that commits at 17:30 (5:30pm) are set to 17:00.
By default limits are disabled.privacy.modeCurrently, only thereducemode is supported. Default isreduce.privacy.passwordDeprecated: Since version 2.0,git-privacyuses key files to encrypt
dates and will automatically migrate from passwords to the new format.This specifies the password used to encrypt the original timestamps.
If no password is given, original timestamps will not be preserved.privacy.patternThis option specifies the extend of the timestamp reduction applied bygit-privacy. The reduction pattern is a string that can comprise the following characters:CharacterMeaningMSets the month to JanuarydSets the day to the first day of the monthhSets the hour to midnightmSets the minute to zero (full hour)sSets the seconds to zero (full minute)If no pattern is specified,git-privacywill abort.privacy.replacementsIf true,git-privacycreates a replacement mapping (git-replace(1))
for each commit that is rewritten by a redate. Default is false.privacy.saltDeprecated: Since version 2.0,git-privacyuses key files to encrypt
dates and will automatically migrate to the new format.This is an auto-generated value created bygit-privacyifpasswordis set
by the user. It should not be altered by the user.A Warning about Git History RewritingAuthor and committer timestamps are part of the commit object and therefore part of
the input that determines the commit hash (the commit's SHA1 value).
Consequently, every modification to a timestamp changes the commit hash.
And since Git uses hash chains, it also changes all commits that build on that
commit, i.e., that have it as an ancestor.Example: Consider the commit sequencea<-b<-c. If you now redateb,cwill also be rewritten under a new commit hash resulting into:a<-b'<-c'.
Ifbandcwere just commits in your local repository, you're probably
fine. But ifborchave been shared with other developers (e.g., by
pushing to a remote), your histories have diverged and you can no longer easily
merge changes from remote.
Do not force-push unless you absolutely know what you are doing!To avoid diverging historiesgit-privacyrejects redates of commits that
are part of any known remote branch.
But you can still run into locally diverging histories, e.g., if you redate
after you have branched of a branch for a feature development.
So keep this in mind when callinggit-privacy redatemanually.
Using the automatic redating of new commits by thepost-commithook or by the--only-headoption should be safe for standard setups.