On Fri, 29 May 2015 03:00:55 -0700 (PDT) [email protected] wrote:
> I want to use git for my cisco config backupdir. In the config files, > there a autogenerated lines with current username and timestamps. To > ignore these lines, I generated a filter. > > ----snip-------------------------------------------------------------------------------------------- > git config filter.ignore_cisco_auto_updates.clean "sed -e '/^! Last > configuration change at/d' -e '/^! NVRAM config last updated at/d' -e > '/^ntp clock-period/d' -e '/^: Written by/d' -e '/^! No configuration > change since/d'" > > git config filter.ignore_cisco_auto_updates.smudge "sed -e '/^! Last > configuration change at/d' -e '/^! NVRAM config last updated at/d' -e > '/^ntp clock-period/d' -e '/^: Written by/d' -e '/^! No configuration > change since/d'" > ----snip-------------------------------------------------------------------------------------------- > > It works fine with one problem. If there is a username in a filtered > out line and the length of the username differs from the one in the > previously commited config, the filesize of the two configs differs > and git status shows this file as changed. > > Is it possible, to ignore the filesize completly, or are there any > other Workarounds? It seems you failed to understand an idea behing the clean/smudge filters machinery. IIUC, support for clean/smudge filters appeared because people mighating from VCS systems of RCS (or even pre-RCS) heritage wanted to use "SCM keywords" in the project files -- something like $Id$ which is expanded by the VCS on checkout to contain, say, the name of the file, the revision it has been last changed in etc (that is, $Id$ becomes $Id: blah.c r12345 1989-02-12 10:00:00 UTC$). On checkin (commit) the VCS removes the content of the keyword changing it back to its "token" form (say, an expanded $Id$ keyword becomes just literally "$Id$" again). As you can see, the contents of the file as seen by those parts of Git which put it into the object database or compare with blobs already existing there always see the *normalized* form -- with those RCS keywords always unexpanded. In other words, smudge filter *puts* stuff in a file and clean filter *removes* stuff from the file. And both filters in the pair MUST hold an invariant: if the contents of the file did not change after the smudge filter worked, the clean filter must produce the content identical to that on which the smudge filter worked when it was called. Your filters break the invariant by only removing stuff. Now back to your problem. I honesly do not understand what happens: in your case the smudge filter should be a no-op as it would try to delete stuff already deleted by the clean filter. So... Are you sure your clean filter really runs or that it indeed drops the stuff it has to drop? To verify this, try inspecting the raw contents of that file. Something like: $ git show --raw HEAD:path/to/your/config/file I'm not sure --raw will help, so you can do it more manually by inspecting trees using `git ls-tree` and `git cat-file`. In either case, you do not need your smudge filter and can (and should) drop it completely. While being useless, it might actually hide the problem of the clean filter not running or not doing its work properly. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
