Roger Leigh wrote:
quoted text
> 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/.
> 

You can. The way to ask explicitly right now is to write hooks
that implement the functionality you want. It's not as easy as
setting a config value, but since you'd have to write the patch
to do that anyways (and it's likely it will get dropped), you'd
be better off writing some hooks and submitting them as contrib
stuff.

quoted text
> 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).
> 

I believe someone else has done some work along the way of
turning git into complete-with-metadata backupsystem before.
Google might prove beneficial.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html