On Thu, Nov 20, 2008 at 09:38:28AM +0100, Andreas Ericsson wrote:
quoted text
> Matthias Kestenholz wrote:
>> Hi,
>>
>> On 19.11.2008, at 12:37, Roger Leigh wrote:
>>
>>> 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
>>>
>>> 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.

This is the approach I'm currently taking, since it's simple and
doesn't require any tool changes.  Ideally, I'd like to avoid
such hackiness, though.

I understand all the arguments I've seen in favour of not using the
mtime of the files when checking out.  They make sense.  However,
in some situations (such as this), they do not--git is breaking
something that was previously working.  In my case, I'm
injecting *release tarballs* into git, and the timestamps on the
files really do matter.  Regarding issues with branching and branch
switching, I always do builds from clean in this case.

If an option was added to git-checkout to restore mtimes, it need
not be the default, but git could record them on commit and then
restore them if asked /explicitly/.

For this, and some other uses I have in mind for git, it would be
great if git could store some more components of the inode
metadata in the tree, such as:
- mtime
- user
- group
- full permissions
- and also allow storage of the full range of file types (i.e.
  block, character, pipe, etc.)

This would allow git to be used as the basis for a complete
functional versioned filesystem (which I'd like to use for my
lightweight virtualisation tool, schroot, which currently
uses LVM snapshots for this purpose).


Regards,
Roger

--=20
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.