Re: converting gnulib: cvs to git

[Simon Josefsson]

Jim Meyering <address@hidden> writes:

> Simon Josefsson <address@hidden> wrote:
>> Jim Meyering <address@hidden> writes:
>>> Does anyone object to my removing the $Id...$ strings from those files?
>>> They will serve no purpose once we migrate.
>>
>> I'd rather not remove them as long as we are using CVS as the master
>> repository.
>>
>> Once, or if, we make the switch to something else, we should replace
>> them with git's equivalent tags (how do they look and behave?).  I
>> find these markers useful when comparing file dates when updating old
>> software, and I think it would be a clear disadvantage if moving to
>> git won't make the same thing possible.
>
> Hi Simon,
>
> Do you really care whether any of the following files (the only ones
> affected in gnulib) contain an CVS/RCS-style $Id...$ string?
>
>    COPYING
>    config/srclist-update
>    config/srclist.txt
>    config/srclistvars.sh
>    doc/Makefile
>    doc/gnulib.texi

No, I don't care for those files.  For those files, I actually believe
it is a good idea to remove the markers.  I was talking generally, and
mostly about code.  Perhaps it is more constructive to analyze this
problem file-by-file.

>    gnulib-tool

Maybe, but I don't feel strongly about it.

Btw, gendocs.sh uses:

scriptversion=2006-07-15.08
...
# Local variables:
# eval: (add-hook 'write-file-hooks 'time-stamp)
# time-stamp-start: "scriptversion="
# time-stamp-format: "%:y-%02m-%02d.%02H"
# time-stamp-end: "$"
# End:

I've found it helpful to look at that timestamp several times when
synchronizing the file between projects, and updating it with my local
patches.  (Now that the file is in gnulib, with all my patches, I just
trust that gnulib contains the latest version, but it hasn't always
been like that.)  Actually, I had mentally assumed that gendocs.sh
contained a CVS $Id...$, as a rationale for my opinion regarding CVS
markers earlier, but now that I look at the file, it was only a
somewhat-reliable timestamp.  Maybe those are sufficient.

/Simon