You are here
When using git as the vcs for etckeeper, I'm finding alot of commit messages that read 'daily autocommit' or 'saving uncommitted changes in /etc prior to/after apt run'. These really clutter up the repository and make it difficult to read, and it doesn't take that many days of autocommits to really clutter up the messages in the repo.
Worse yet, if I leave changes out there and forget to commit them, then they end up getting included in the chron-job commit with a generic message.
The solution to all this appears to be rewriting history (rebasing the repository) at least earily on in the life of the server when you are first setting it up. Running rebase -i <initial-commit-SHA1-Hash> allows you to do the following when it displays a First-Commit-to-Last-Commit sorted overview list in the editor (note this is the opposite of the sort order displayed by default in the git log command):
| reword |
Change the commit message to something else Adding this will result in a vim window that allows you to change the commit title and commit message for the specified commit. |
| edit |
To make changes to the commit itself, this also allows us to split out files may have been accidently included in a daily commit.
|
| pick | The default operation; this includes a commit in history. |
| fixup | Condenses the commit with it's parent and merge them together (useful for joining a bunch of those `daily autocommit` changesets together) |
| (reorder) | Though not an option, you can take the lines that represent a commit and put them in a different order, so that the changesets are applied in a different order, and so that they appear in the git logs in a different order...though this is probably pretty dangerous if you aren't sure your commits are very atomic |
However after running a rebase on the repository we have to re-run etckeeper pre-commit so that all the permissions and meta data are fixed within etckeeper.
Now if you are the only one maintaining a repo for a given server this rewriting of history is all well and good, but if you have other people working in it, they need to be notified of the changes and this is not quite as easy, because all of the commits hashes have to be re-calculated when history is rewritten (though if you don't change or remove the commits the messages will stay the same).
So I guess my question here is, is there any value to having a daily commit message? Its it okay for me to consolidate those (at least the ones in the past) to provide a cleaner easier to read commit history? What do you with those messages?
Thank you,
leeand00
Webmin is not well behaved
Ah this appears to be the source of many of my woes. But I'm still going to have to rewrite that commit history.
TBH I haven't looked into this too much
As the .gitignore file was updated in May, the current v14.0 appliances should be much better. Are you still seeing junk that shouldn't be there?
Beyond poorly behaving apps (i.e. Webmin) IMO an auto commit with a not so useful message and a jumble of changes is superior to losing config file changes altogether.
Also IMO there is absolutely nothing wrong with consolidating previous commits (or possibly even deleting them altogether after some time). Obviously it's not ideal for a normal git repo (re-writing history is not a great idea in any shared repo) but etckeeper's management of /etc is not a normal git repo! :)
Add new comment