On Fri, 29 May 2015 03:00:55 -0700 (PDT)
thomas.bergjuer...@googlemail.com 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 git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to