On Sun, May 15, 2011 at 11:53 AM, Dan Stillman <[email protected]> wrote:
> On 5/15/11 9:24 AM, Rintze Zelle wrote:

...

>> I just mean the cs:updated timestamp should reflect the time and date
>> of the last style edit.
>
> Do you mean cs:updated, or do you mean the index timestamp? Remember,
> the reason we advised leaving cs:updated blank in the styles was so that
> authors wouldn't feel compelled to update it on every update, which
> would be a waste of their time. (I know there was the issue of whether
> the styles still validated client-side...)

There are a variety of issues with forcing style authors to update the
cs:updated values manually:

- it's tedious
- it's error prone (easy to forget to do, most basically)
- it mixes content and metadata (the metadata changes the sha1 value)

> The problem with using smudge/clean filters in .gitattributes is that,
> as far as I can tell, they require particular client-side programs
> (e.g., Perl). A Windows user isn't going to have Perl. So leaving it
> blank seems best.

"Leaving it blank" but presumably using some other code outside of git
to create the proper cs:updated values?

In any case, users aren't often going to interact with the git repos
directly, so not sure that's a reasonable argument against the git
filters?

> None of the date logic on the styles page changed, by the way. The
> timestamps will be correct as the styles are updated. It's just more
> complicated to use the commit timestamp than to update the timestamp if
> the style has changed, and so I didn't bother.

Not following you here. Can you restate, in light of my questions above?

Thanks,
Bruce

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
xbiblio-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/xbiblio-devel

Reply via email to