Re: git and mtime

From: Andreas Ericsson <ae@op5.se>
Date: Nov 20, 2008, 08:38 UTC
Message-ID: <49252204.2070906@op5.se>
In-Reply-To: <C33ABF98-2E52-4928-BF79-CB3B6A8460DB@feinheit.ch>

Matthias Kestenholz wrote:

Show 33 quoted lines

> 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@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231