Re: Git checkout preserve timestamp?

On Mon, Mar 05, 2007 at 05:38:07PM -0600, Bill Lear wrote:

Are you assuming that the makefile will automatically figure out which branch you are on, and then redirect the .o to the right <.branch-name> directory? That's the only thing that makes sense, since if you are using VPATH and depending on the developer being cd'ed into .master when the current branch is master, and cd'ed into .branchX when the current branch is branchX, and the developer types make at when they are in the .master directory but the current branch is branchX, the result will be a huge, confusing mess.

But of course, the Makefile is under source control itself, and if at a previous point in time the Makefile didn't have the magic .git directives, then you could do the build and have the the wrong thing happen.

So it seems to be a very fragile solution compared to using multiple working directories, or using ccache. It could be a tad bit more efficient than using ccache or multiple directories, but the real question is whether it really is worth the effort, and potential support difficulties if some confused user turns on this feature with the proper git magic in their makefiles, and then the git mailing list gets the support burden.

That being said, I have often wished that there was some way I could use all of those autogenerated html and man pages to spead up the "make doc" process in git. Ccache doesn't work because it doesn't understand asciidoc or xmlto, and there are all of these conveniently generated output files in the origin/man and origin/html, but unless we are building exactly the same git release as described in the log message in the origin/man or origin/html branch.

What would be really cool would be some way of generating some kind of database that mapped the SHA1 hash of the SHA1 hash of the dependencies of a particular output file to the SHA1 hash of the glob of the generated output file as found in origin/man and origin/html. This would basically be a way of integrating ccache functionality into git, but for the HTML and man page outputs, which delta compress nicely and therefore makes a lot of sense to include in a git repository like Junio is doing already. I'm not sure how much sense this would make for storing the .o globs in the git repository (although there are some SCM's, like Clearcase who do this), but in theory it could be used for that as well. The case is much more compelling with the generated documentation files, though.

					- Ted