> -----Original Message-----
> From: Johannes Sixt [mailto:j.s...@viscovery.net]
> Sent: Friday, September 14, 2012 10:40 AM
> To: Mestnik, Michael J - Eagan, MN - Contractor
> Cc: Michael J Gruber; email@example.com
> Subject: Re: Using Format/export-subst Howto.
> Am 9/14/2012 17:27, schrieb Mestnik, Michael J - Eagan, MN -
> >> -----Original Message----- From: Johannes Sixt
> >> If EOL conversion or a clean filter was applied during 'git add
> >> file', is the version in the worktree suddenly wrong? Of course,
> >> not.
> >> I would place $Id$ treatment in the same ball park and
> declare it as
> >> a mistake of the editor that it did not remove the now "wrong" SHA1
> >> from $Id:$.
> > I think the difference here is that git does not *currently
> change the
> > OS's LEF. In this case each commit alters the Id and git is the one
> > altering the Id.
> Maybe you misunderstood $Id$? The value you get there is the
> blob's SHA1,
> not the commit's. That is, it does not change on every
> commit, but only
> when the file changes.
> You are right that the value itself is something that is
> dictated by git's
> database model, but the change logically happens when the
> editor modifies
> the file.
> (My contribution to this thread should be regarded as food
> for thought.
> Personally, I don't mind whether or not and when $Id$ is updated.)
Thank you for correcting me, I've always noticed this number doesn't seam to
correlate to anything of use for me. However it's been helpful when reading
these reports to see what version generated it and that's why I wanted to
further expand the information provided... The date and time of the commit are
specifically useful to me.
> -- Hannes
Mike Mestnik, Michael J
The ESM Tools
Enterprise Systems Monitoring
United States Postal Service
O: (651) 406-2048
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html