[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: converting gnulib: cvs to git
From: |
Simon Josefsson |
Subject: |
Re: converting gnulib: cvs to git |
Date: |
Mon, 04 Dec 2006 23:20:56 +0100 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.91 (gnu/linux) |
Paul Eggert <address@hidden> writes:
> Simon Josefsson <address@hidden> writes:
>
>> 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.
>
> They are controversial. I'd rather remove them, at least in the files
> I help maintain. They cause me more problems than they cure, because
> they introduce spurious changes. Call me an Aristotelian if you like,
> but I prefer to keep metadata separate from data.
Problem is that CVS meta-data is typically not preserved in the stuff
that you get as end-user, which sometimes is the only source you have
when doing some archaeological expedition into old code.
Ideally, I'd like for the CVS (or git, or whatever) meta-data to be
exported and distributed along with the source code. Using cvs2cl to
generate ChangeLog's from cvs log does a big part of that, but it
isn't a perfect solution.
> While I'm throwing oil onto the fire, I have a similar opinion of the
> version numbers we maintain in the .m4 files. They're even worse,
> since they're maintained by hand.
FWIW, I have never understood the point of those version numbers. The
only reason that I can imagine, of maintaining version numbers on .m4
files, is if there is some shared library alike versioning for
backwards compatibility going on, but there isn't, as far as I know.
I'd be happy to drop those fields too. They don't contain a date, and
are not reliably updated, so I don't see any practical purpose for
them.
/Simon
Re: converting gnulib: cvs to git, Eric Blake, 2006/12/26