|
1 | 1 | #!/usr/bin/env bash
|
2 | 2 | #
|
3 | 3 | # Append a trailer with the commit hash to every commit message.
|
4 |
| -# This can be useful if you rewrite the history later on and you want |
5 |
| -# to preserve the original commit hashes. |
| 4 | +# |
| 5 | +# # Why would you do this? |
| 6 | +# |
| 7 | +# Git commit hashes change when you rewrite history. If you release your |
| 8 | +# software with the exact build hash (you should, it eases debugging!), |
| 9 | +# then all released hashes won't be in your repository anymore. If you |
| 10 | +# add the original hashes to the commit messages, then you can find them |
| 11 | +# even after a history rewrite. |
| 12 | +# |
| 13 | +# Another use case for the original hashes is if you keep the original |
| 14 | +# repository as archive for reference (e.g. because your industry |
| 15 | +# requires you to keep *exactly* every state of the repositiry). The |
| 16 | +# hash in the commit message will help you to find the corresponding |
| 17 | +# commit in the original repository if necessary. |
6 | 18 | #
|
7 | 19 | # Attention: Since the commit message is part of the commit hash
|
8 | 20 | # calculation, this script changes the commit hashes too.
|
|
16 | 28 | # starting with refs/original/, unless forced.
|
17 | 29 | # See `man git-filter-branch`
|
18 | 30 | #
|
| 31 | +# Example: |
| 32 | +# Purge the file `foo.dat` from the repository: |
| 33 | +# |
| 34 | +# Step 1: Run `git-append-commit-trailer` |
| 35 | +# Step 2: git-purge-files foo.dat |
| 36 | +# |
| 37 | +# Result: The file `foo.dat` was purged from the history and every |
| 38 | +# commit message has a link (original commit hash) to the |
| 39 | +# original version. |
| 40 | +# |
19 | 41 | # Author: Lars Schneider, https://github.com/larsxschneider
|
20 | 42 | #
|
21 | 43 |
|
|
0 commit comments