Matthias Kestenholz wrote:
Hi,
On 19.11.2008, at 12:37, Roger Leigh wrote:
Hi folks,
I'm using git to store some generated files, as well as their sources.
(This is in the context of Debian package development, where entire
upstream release tarballs are injected into an upstream branch, with
Debian releases merging the upstream branch, and adding the Debian
packaging files.)
The upstream release tarballs contains files such as
- yacc/lex code, and the corresponding generated sources
- Docbook/XML code, and corresponding HTML/PDF documentation
These are provided by upstream so that end users don't need these tools
installed (particularly docbook, since the toolchain is so flaky on
different systems). However, the fact that git isn't storing the
mtime of the files confuses make, so it then tries to regenerate these
(already up-to-date) files, and fails in the process since the tools
aren't available.
Would it be possible for git to store the mtime of files in the tree?
This subject comes up from time to time, but the answer always
stays the same: No. The trees are purely defined by their content, and
that's by design.
If you do not want to regenerate files that are already up-to-date,
you need multiple checkouts of the same repository.
Or a make-rule that touches the files you know are up to date. Since you
control the build environment, that's probably the simplest solution.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html