I am not an expert. In blunt fact, I'm rather new with git. But I looked at 
the documentation you mentioned
here: http://www.kernel.org/pub/software/scm/git/docs/gitattributes.html

>From my reading, the only processing which you can modify is the "filter" 
one. The "ident" does one only one "hard wired" thing:

When the attribute ident is set for a path, git replaces $Id$ in the blob 
object with $Id:, followed by the 40-character hexadecimal blob object 
name, followed by a dollar sign $ upon checkout. Any byte sequence that 
begins with $Id: and ends with $ in the worktree file is replaced with $Id$ 


I guess this is done so that your source could be compiled with a string in 
it which contains the "40-character hexadecimal blob object name". Perhaps 
so that a --version switch could display it so that you'd know exactly 
which "patch level" the running code is using.

The "text" filter also only does one specific thing:

This attribute enables and controls end-of-line normalization. When a text 
file is normalized, its line endings are converted to LF in the repository. 
To control what line ending style is used in the working directory, use the 
eol attribute for a single file and the core.eol configuration variable for 
all text files.

The documentation says that this is to "normalize" the line endings for 
text files between systems. Especially UNIX, which likes a single LF 
(0x0A), and Windows, which likes a CRLF (0x0D,0x0A).

So no you cannot "wire anything to any of them". You can only wire into the 
"filter" process. The other two have a fixed, unchangeable, meaning.

At least as best as I can understand it without looking at the actual 
source code. Which I am: (1) too lazy to do and (2) not competent to do 

On Wednesday, September 19, 2012 4:21:46 AM UTC-5, lalebarde wrote:
> Hi all,
> From the gitattributes documentation :
>> Interaction between checkin/checkout attributes
> In the check-in codepath, the worktree file is first converted with filter 
>> driver (if specified and corresponding driver defined), then the result is 
>> processed with ident (if specified), and then finally with text (again, if 
>> specified and applicable).
> In the check-out codepath, the blob content is first converted with text, 
>> and then ident and fed to filter.
> So we have :
>     check-in : INDEX ---> filter ---> ident ---> text ---> REPOSITORY
>     check-out : REPOSITORY ---> text ---> ident ---> filter ---> WORKSPACE
> *Questions :*
> *Are filter, ident, text identical*, in the meaning I can wire anything 
> to any of them ? So they have been name like this for easier workflow 
> understanding and set-up, but they could have been named anything as 
> filter1, filter2, filter3 ?


Reply via email to