On Sat, 21 Apr 2007, Junio C Hamano wrote:
The interface is similar to the custom low-level merge drivers.
First you configure your filter driver by defining 'filter.<name>.*'
variables in the configuration.
filter.<name>.clean filter command to run upon checkin
filter.<name>.smudge filter command to run upon checkout
Then you assign filter attribute to each path, whose name
matches the custom filter driver's name.
Example:
(in .gitattributes)
*.c filter=indent
(in config)
[filter "indent"]
clean = indent
smudge = cat
hmm, three things come to mind here
1. it would be useful in many cases for the filter program to know what file
it's working on (and probably some other things), so there are probably some
command-line arguments that should be able to be passed to the filter.
2. should this be done as a modification of the in-memory buffer (s this patch
does it?) or should it be done at the time of the read/write, makeing the filter
be responsible for actually doing the disk I/O, which would give it the benifit
of being able to do things like set permissions and other things that can't be
done until the file is actually on the filesystem (for something managing config
files, this could include restarting the daemon related to the config file for
example)
3. why specify seperate clean/smudge programs instead of just one script with a
read/write parameter? I suspect that in most cases the external filter program
that cleans files will be the same one that smudges them. the clean/smudge
version does let you specify vastly different things without requireing a
wrapper script around them, but it would mean duplicating the line when they are
the same.
the first two items seem fairly important to me, but the third is a niceity that
I could live with as-is.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html