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:
ident
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$
upon
check-in.
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:
text
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
anyway.
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 ?
>
>
--
