On Wed, Nov 22, 2006 at 07:42:58PM +0100, Bruno Haible wrote:
> Hello Sylvain,
>
> Can you please tell: Are the git repositories visible in
>
> http://git.sv.gnu.org/gitweb/
>
> stored on a disk that is regularly backed up? If so, with which frequency
> (daily, weekly, monthly)?
>
> I'm
Ben Pfaff <[EMAIL PROTECTED]> writes:
> I don't understand this rationale. C89 requires that the switch
> expression be of integral type. For C89 compilers with the long
> long int extension, a long long int is an integral type
No, because there's no standard for the "long long int" extension i
Jim Meyering <[EMAIL PROTECTED]> writes:
> Thanks, but that doesn't matter. When st_size is used that way (when
> ->fts_info == FTS_NSOK), its value must be FTS_STAT_REQUIRED (1) or
> FTS_NO_STAT_REQUIRED (2). If there is a way to make it have any other
> value, it's a bug.
Yes, but the point o
Paul Eggert <[EMAIL PROTECTED]> writes:
> Come to think of it, since we want the code to stay portable to C89,
> then we can't use switch (V) ... when V is of type off_t. This is
> because off_t is typically 'long long int', and C89 (which lacks 'long
> long int') does not require support for a s
Paul Eggert <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>> +enum Fts_stat need_stat = p->fts_statp->st_size;
>> +switch (need_stat)
>
> Dunno if this matters, but on typical 64-bit platforms converting to
> enum Fts_stat and then switching w
Jim Meyering <[EMAIL PROTECTED]> writes:
> + enum Fts_stat need_stat = p->fts_statp->st_size;
> + switch (need_stat)
Dunno if this matters, but on typical 64-bit platforms converting to
enum Fts_stat and then switching won't abort in the rare cases when
p->fts_stat
Jim Meyering <[EMAIL PROTECTED]> writes:
> Thanks for the report and patch.
> What version of HP-UX (and, if possible, the compiler) is that?
> It must be rather old.
Come to think of it, since we want the code to stay portable to C89,
then we can't use switch (V) ... when V is of type off_t. Th
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> Ok, happen to have a quick how-to? (A cron job that *doesn't* mail me
> unless there is a problem would be nice :-).)
http://buildbot.sourceforge.net/
I haven't built one myself, but others have
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> The OS is 11.00, and I can't tell about the compiler ('cc -v' is giving
FYI, I've checked in a slightly different change:
Work around a compile-time error from the HP-UX 11.00 /bin/cc.
* lib/fts.c (enum Fts_stat): Give this previously-a
Jim Meyering wrote:
Matthew Woehlke wrote:
I got the following error (in gnulib) building coreutils 6.6 on HP-UX.
source='fts.c' object='fts.o' libtool=no \
DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \
cc -I. -I/home/install/gnu/hp700_hpux/include -g -c fts.c
cc:
Matthew Woehlke <[EMAIL PROTECTED]> wrote:
> I got the following error (in gnulib) building coreutils 6.6 on HP-UX.
>
>> source='fts.c' object='fts.o' libtool=no \
>> DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \
>> cc -I. -I/home/install/gnu/hp700_hpux/include -g -c
I got the following error (in gnulib) building coreutils 6.6 on HP-UX.
source='fts.c' object='fts.o' libtool=no \
DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \
cc -I. -I/home/install/gnu/hp700_hpux/include -g -c fts.c
cc: "fts.c", line 734: error 1654: Expression ty
[EMAIL PROTECTED] (Karl Berry) wrote:
...
> but we'd commit changes only against the git repo
>
> That was my point. Have you written a cheat sheet for coreutils git
> users? Or maybe one exists independently? You know,
> (a) how to check out
On the command line, it's probably best to start
Bruno Haible <[EMAIL PROTECTED]> wrote:
...
>> > - automatic daily backup,
>>
>> Not relevant.
>> With git or hg, anyone who pulls gets the entire repository.
>
> Hmm, but if the central repository got lost, and was restored through - say -
> my copy, everyone would see my temporary branches,
No
Paul Eggert wrote:
Matthew Woehlke writes:
I could probably do it on
this box, but since it's Linux, it would still be with gcc.
Even that would be helpful, since our current buildbot doesn't do the
particular combination of GCC options you're interested in.
Ok, happen to have a quick how-to
Matthew Woehlke <[EMAIL PROTECTED]> writes:
> I could probably do it on
> this box, but since it's Linux, it would still be with gcc.
Even that would be helpful, since our current buildbot doesn't do the
particular combination of GCC options you're interested in.
Karl Berry wrote:
> As I understand it, the reason for the proposal is because branches are
> supported better in git. But isn't wanting to make branches tantamount
> to making releases?
The reasons to make branches are:
1) for temporary small changes, testing etc.,
2) for adding features tha
[EMAIL PROTECTED] wrote:
> It'd be a blank slate for me, learning git from ground up.
There are two tutorials for people with a CVS background:
http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html
http://git.or.cz/course/cvs.html
> How well/easily would git sessions work thru fi
Hello Sylvain,
Can you please tell: Are the git repositories visible in
http://git.sv.gnu.org/gitweb/
stored on a disk that is regularly backed up? If so, with which frequency
(daily, weekly, monthly)?
I'm asking because we are considering moving gnulib to this area as well.
Bruno
> > Do you have a comparison of git with mercurial, monotone, bzr?
Reading the wikipedia articles on each of them
http://en.wikipedia.org/wiki/Git_(software)
http://en.wikipedia.org/wiki/Mercurial_(software)
http://en.wikipedia.org/wiki/Monotone_(software)
http://en.wikipedia.org/wiki/
My suggestion to use a dVCS was mostly independent of branching.
Oh. Sorry, I didn't get that.
but we'd commit changes only against the git repo
That was my point. Have you written a cheat sheet for coreutils git
users? Or maybe one exists independently? You know,
(a) how to check ou
Robinson Mittmann wrote:
> Looking at the "kernel_sinl" function in "sincosl.c" file I found that
> the limit value for choosing the computation method is wrong with
> respect of the remaining code:
>
> kernel_sinl (long double x, long double y, int iy)
> {
> ...
> if (x < 0.148375L)
[EMAIL PROTECTED] (Karl Berry) wrote:
> this change would not force you to learn about or use git.
>
> Granting that git is a zillion times better than cvs, even so, far fewer
> people can contribute to a git repository than cvs.
>
> As I understand it, the reason for the proposal is because br
this change would not force you to learn about or use git.
Granting that git is a zillion times better than cvs, even so, far fewer
people can contribute to a git repository than cvs.
As I understand it, the reason for the proposal is because branches are
supported better in git. But isn't w
Looking at the "kernel_sinl" function in "sincosl.c" file I found that
the limit value for choosing the computation method is wrong with
respect of the remaining code:
kernel_sinl (long double x, long double y, int iy)
{
...
if (x < 0.148375L)/* |x| < 0.1484375 */
The correct line sh
FYI, I've just checked these in:
* m4/clock_time.m4 (gl_CLOCK_TIME): Quote AC_SUBST argument.
* m4/euidaccess.m4 (gl_PREREQ_EUIDACCESS): Likewise.
Index: m4/clock_time.m4
===
RCS file: /sources/gnulib/gnulib/m4/clock_
<[EMAIL PROTECTED]> wrote:
> On 2006-11-21 07:56:27 -0600, Jim Meyering <[EMAIL PROTECTED]> said:
>> Would anyone be averse to switching gnulib development from CVS to git?
>> I switched coreutils a month ago and am very happy with the result.
>
> I found this Fink pkg -- is it the same thing?
> ht
Jim Meyering <[EMAIL PROTECTED]> wrote:
> Bruno Haible <[EMAIL PROTECTED]> wrote:
>> Jim Meyering wrote:
>>> Would anyone be averse to switching gnulib development from CVS to git?
>>> I switched coreutils a month ago and am very happy with the result.
>>
>> Do you have a comparison of git with mer
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> Would anyone be averse to switching gnulib development from CVS to git?
>> I switched coreutils a month ago and am very happy with the result.
>
> Do you have a comparison of git with mercurial, monotone, bzr?
There are *lots* of git
29 matches
Mail list logo
