On Thu, Nov 20, 2008 at 09:38:28AM +0100, Andreas Ericsson wrote: > 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 -- .''`. 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.
Attachment:
signature.asc
Description: Digital signature
