On Thu, 20 Nov 2008, Roger Leigh wrote:

quoted text
> On Wed, Nov 19, 2008 at 05:18:16PM +0100, Christian MICHON wrote:
> > On Wed, Nov 19, 2008 at 12:37 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> > > Would it be possible for git to store the mtime of files in the tree?
> > >
> > > This would make it possible to do this type of work in git, since it's
> > > currently a bit random as to whether it works or not.  This only
> > > started when I upgraded to an amd64 architecture from powerpc32,
> > > I guess it's maybe using high-resolution timestamps.
> > >
> > 
> > beside the obvious answer it comes back often as a request, it is
> > possible in theory to create a shell script which, for each file
> > present in the sandbox in the current branch, would find the mtime of
> > the last commit on that file (quite an expensive operation) and apply
> > it.
> 
> Surely this is only expensive because you're not already storing the
> information in the tree; if it was there, it would be (relatively)
> cheap?  You could even compare the old and new trees to see if you
> needed to touch a file at all.
> 
> > You should store mostly content of source files. You should do a make
> > in your first cloned repo at least once before committing anything to
> > the repo. That's what I did and I saved days...
> 
> Except in this case I'm storing the content of *tarballs* (along with
> pristine-tar).  I'm committing exactly what's in the tarball with
> no changes (this is a requirement).  I can't change the source prior
> to commit.

Can you store the tarballs in the repository, instead of the contents of 
the tarballs? The tarballs will contain the dates you want, and you can 
obviously get tar to set the timestamps the way you want. (Then you add a 
higher-level Makefile that knows how to unpack the tarball to a directory, 
maintaining the timestamps, patch anything you're changing, and run make 
in that directory.)

That is to say, from your perspective, the sources include the upstream 
distributed tarballs, but the individual files in upstream tarballs aren't 
source files for you, since you can't (by policy) modify them (within the 
pristine tarball). If you want to change the sources of the packaged 
project, you add a patch file to do it, rather than simply changing the 
source (which, as you say, you're required not to do).

Git really wants to store the inputs to your workflow, each of which might
change independently. That's why the files in your work tree have 
timestamps based on when they came to be in your work tree (get set to the 
current time whenever git puts different content there, and leaves them 
unchanged if their contents don't change when moving from commit to 
commit). The "sources" in your workflow are a different set of files from 
the sources in the project, and git really wants *your* repository to 
match *your* workflow and not the workflow of the upstream project, when 
you're acting as a packager rather than an upstream developer.

	-Daniel
*This .sig left intentionally blank*
--
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