I use etckeeper on some of my systems, backed by Git. On a system still using a SYSV style init I recently modified my iptables settings, changing which runlevels would stop/start the firewall.
[root@drew-northup ~]# etckeeper vcs status # On branch master # Changes not staged for commit: # (use "git add/rm <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: inittab # deleted: rc.d/rc2.d/K92iptables # deleted: rc.d/rc3.d/K92iptables # deleted: rc.d/rc4.d/K92iptables # deleted: rc.d/rc5.d/K92ip6tables # modified: sysconfig/ip6tables # # Untracked files: # (use "git add <file>..." to include in what will be committed) # # rc.d/rc2.d/S08iptables # rc.d/rc3.d/S08iptables # rc.d/rc4.d/S08iptables # rc.d/rc5.d/S08ip6tables no changes added to commit (use "git add" and/or "git commit -a") It detects the changes as renames however—which in this case isn't appropriate: [root@drew-northup ~]# etckeeper vcs status # On branch master # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # renamed: rc.d/rc2.d/K92iptables -> rc.d/rc2.d/S08iptables # renamed: rc.d/rc3.d/K92iptables -> rc.d/rc3.d/S08iptables # renamed: rc.d/rc4.d/K92iptables -> rc.d/rc4.d/S08iptables # renamed: rc.d/rc5.d/K92ip6tables -> rc.d/rc5.d/S08ip6tables # # Changes not staged for commit: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # modified: inittab # modified: sysconfig/ip6tables # Is there something I should be doing to suppress rename detection in this case? (I presume changing the default—detecting as a rename—isn't such a bright idea.) [root@drew-northup ~]# etckeeper vcs --version git version 1.7.11.3 -- -Drew Northup ________________________________________________ "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
