Roger Leigh wrote:
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.
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@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
