On Mon, Aug 22, 2011 at 20:10, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote: > On 22 August 2011 12:31, Kyle Moffett <kyle@xxxxxxxxxxxxxxx> wrote: >> On Mon, Aug 22, 2011 at 14:49, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote: >>> On 22 August 2011 05:46, Kyle Moffett <kyle@xxxxxxxxxxxxxxx> wrote: >>>> On Mon, Aug 22, 2011 at 01:36, Hilco Wijbenga <hilco.wijbenga@xxxxxxxxx> wrote: >>>>> On 21 August 2011 20:01, Kyle Moffett <kyle@xxxxxxxxxxxxxxx> wrote: >>>> In particular, even "git stash" intentionally does not preserve file times, >>>> so you would end up rebuilding everything anyways because all of your >>>> source files would be as new as your object files. >>> >>> Yes, I just noticed that. Why do you say "intentionally"? Is extra >>> work being done to make it so? If yes, then shouldn't that be >>> configurable? >> >> Well, there's 2 reasons: >> >> (1) The GIT data-structures simply have no place for file timestamps, and >> "git stash" is simply a special way of dumping files into a temporary commit. > > That's what I thought. The "intentionally" threw me off. It's not > intentional, it's just a side effect. No, it's intentional. This discussion about timestamps is not new; the mailing list is littered with people wondering about it. The data structures are the way they are for intentional reasons, as suggested by Kyle's example. >> (2) You almost always *don't* want to preserve timestamps. For example: >> >> $ git checkout -b my-feature origin/master >> $ vim some-file.c >> $ make >> $ git add some-file.c && git commit -m "A new feature" >> $ git checkout -b my-bugfix origin/master >> $ vim other-file.c >> $ make >> >> If GIT preserved timestamps, the second "make" would fail to rebuild the >> product "some-file.o" because "some-file.c" is still older than it, even >> though "some-file.c" has changed since the last build!!! >> >> Really, GIT is only intended for storing source code. If you want to store >> other kinds of things (like timestamps, permissions, etc), then you need to >> turn them into source code (IE: a text file and a "make install" target) and >> then store them that way. > > Yep, that all makes sense. I just wish there was at least an option to > keep the timestamp (and possibly other such things). Even Subversion > can do that... ;-) After all, not everybody uses C & make. Yes, well, the crux there is `(and possibly other such things)'. That is an open-ended specification because nobody can agree on what such things should include. One of git's major design goals has been efficiency, so it's natural that git only handles what is necessary for its prime purpose of managing a history of line-oriented textual content. However, other tools have been built on top of git's infrastructure in order to store all manner of metadata (usually for the purposes of backing up files with all of their special metadata). Essentially, only *you* know what `other such things' *you* need, so it's up to you to design a way of storing such information and retrieving it yourself. After all, not everybody (indeed, nearly nobody, I'd wager) has your specific difficulties. -- 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