# [PATCH] Documentation: clarify information about 'ident' attribute 2 messages from 2008-10-30 to 2008-10-30. Participants: Jan Krüger, Junio C Hamano. Thread: https://gitlist.dev/t/16100 ## Jan Krüger, 2008-10-30 18:14 Subject: [PATCH] Documentation: clarify information about 'ident' attribute Message-ID: <20081030191433.710aff11@perceptron> URL: https://gitlist.dev/e/20081030191433.710aff11%40perceptron ``` The documentation spoke of the attribute being set "to" a path; this can mistakenly be interpreted as "the attribute needs to have its value set to some kind of path". This clarifies things (and also calls the object ID a hash rather than a name because that might be confusing too). Signed-off-by: Jan Krüger --- Confused me and a few other people on IRC the other day. Documentation/gitattributes.txt | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt index 2694559..b39db6b 100644 --- a/Documentation/gitattributes.txt +++ b/Documentation/gitattributes.txt @@ -163,9 +163,9 @@ few exceptions. Even though... `ident` ^^^^^^^ -When the attribute `ident` is set to a path, git replaces -`$Id$` in the blob object with `$Id:`, followed by -40-character hexadecimal blob object name, followed by a dollar +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 hash, 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. -- 1.6.0.3.523.g304d0.dirty ``` ## Junio C Hamano, 2008-10-30 19:30 Subject: Re: [PATCH] Documentation: clarify information about 'ident' attribute Message-ID: <7vfxmdev8w.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7vfxmdev8w.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20081030191433.710aff11@perceptron> ``` "Jan Krüger" writes: > The documentation spoke of the attribute being set "to" a path; this can > mistakenly be interpreted as "the attribute needs to have its value set to > some kind of path". This clarifies things (and also calls the object ID a > hash rather than a name because that might be confusing too). I'd agree with the first change, but not with the second. "object name" has been the official name of these hexadecimal thingy for a long time (see the glossary). ```