[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: git head fails to build

From: Neil Jerram
Subject: Re: git head fails to build
Date: Wed, 14 Jan 2009 21:45:22 +0000

2009/1/14 Ludovic Courtès <address@hidden>:
> Hello Neil,
> I've been working on this in parallel, so I thought it'd be better to
> get in sync.  ;-)

Thank you!

> I had (hopefully) fixed the problem by reverting your commits in reverse
> order and starting anew (attached patch).  The problem is that commit
> 4a462e35440fdc3f10b0f88b3fb737fa76ed146d touches way too many files: it
> adds generated `.h' files (which is boring since they then have to be
> removed before one can `pull' or `checkout'), it modifies
> `m4/.gitignore' (which we don't want precisely because we commit
> Gnulib's M4 files), it adds `lib/.gitignore', it modifies `INSTALL',
> etc.

Right.  Since my last message, I realized that Gnulib by default is
assuming that one won't commit its files, and hence it adds them to

> I find it tricky to update Gnulib files since we store them in the repo.
> It's easy when one doesn't store them in the repository because it
> updates `.gitignore', etc., but it gets harder when one stores them in
> the repo.  We should use "gnulib-update --no-vc-files" actually (info
> "(gnulib) VCS Issues"), but we still have to make sure we don't commit
> generated files.

Cool, I'll try to remember that in future.

Your patch looks good - except that we should also delete
libguile/alloca.c.  I can do that in a separate commit if you prefer.

I was on the point of reaching the same endpoint, by doing
$ rm *
$ git checkout master -- .
$ ../../gnulib/gnulib-tool -- import
<edit lib/.gitignore and m4/.gitignore so that they are empty>
$ git status
And then the git status output tells you which Gnulib files should be committed.

But given that your patch is ready to go, please commit it.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]