Hi Sylvain,
As you know, we want to convert gnulib to use git soon. I'd like
to use coreutils as a testbed for that. Currently, the coreutils
master repo is a git one. I manually run a script to mirror its
changes to a cvs repo on my local system. Then, I rsync that
repo to Bob's system (proul
Eric Blake <[EMAIL PROTECTED]> wrote:
> According to Jim Meyering on 12/4/2006 2:21 AM:
>> So far, no one has objected to my proposal to convert gnulib development
>> from cvs to git. If there are any nay-sayers, it's time to speak up.
>>
>> I've just gone through the conversion process once more,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 12/4/2006 2:21 AM:
> So far, no one has objected to my proposal to convert gnulib development
> from cvs to git. If there are any nay-sayers, it's time to speak up.
>
> I've just gone through the conversion process once m
Karl Berry wrote:
>gnulib-tool
>
> That's for Bruno, I expect.
I abstain. The keyword has served its purpose once, by allowing us to easily
diagnose that
a user's gnulib checkout was 6 months old. But OTOH I believe, with Jim, that
git's nonlinear
branch topology makes this unusable in the f
On 4 Dec 2006, Paul Eggert outgrape:
> Simon Josefsson <[EMAIL PROTECTED]> 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 controversi
Hello Simon,
* Simon Josefsson wrote on Mon, Dec 04, 2006 at 11:20:56PM CET:
> Paul Eggert <[EMAIL PROTECTED]> writes:
>
> > 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
$ grep Id COPYING
$Id: COPYING,v 1.3 2006/10/26 16:20:28 eggert Exp $
Oh. I thought you were talking about the GPL "COPYING" file. I don't
think that top-level gnulib file should be named COPYING :). I don't
know if I was responsible for that one, but it seems unlikely Paul was
...
Jim Meyering <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> Jim Meyering <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] (Karl Berry) wrote:
> Do you really care whether any of the following files (the only ones
> affected in gnulib) contain an CVS/RCS-style $Id...$ string?
>
>COPYING
>
> COPYING has no $Id$. What am I missing?
this?
$ grep Id COPYING
$Id: COPYING,v 1.3 2006/1
Paul Eggert <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> 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 controve
Do you really care whether any of the following files (the only ones
affected in gnulib) contain an CVS/RCS-style $Id...$ string?
COPYING
COPYING has no $Id$. What am I missing?
config/srclist-update
config/srclist.txt
config/srclistvars.sh
doc/Makefile
doc/gnulib.
version numbers we maintain in the .m4 files. They're even worse,
They may be worse in the abstract, but I really hope we don't get rid of
them, ever (even aside from the aclocal question). They have proven
*extremely* useful to me in sorting out auto* problems.
karl
Paul Eggert wrote:
> Simon Josefsson <[EMAIL PROTECTED]> 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 r
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> 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.
>
>
Hello Paul,
* Paul Eggert wrote on Mon, Dec 04, 2006 at 08:14:00PM CET:
>
> 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.
Except the serial numbers also have a technic
Simon Josefsson <[EMAIL PROTECTED]> 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 fi
Jim Meyering <[EMAIL PROTECTED]> 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
So far, no one has objected to my proposal to convert gnulib development
from cvs to git. If there are any nay-sayers, it's time to speak up.
I've just gone through the conversion process once more, and
pushed the result to the usual place:
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=summary
18 matches
Mail list logo
