{"thread":{"id":"7042","subject":"Git checkout preserve timestamp?","startedAt":"2007-03-01T21:36:25Z","lastAt":"2007-03-06T18:39:17Z","messageCount":51,"participants":["Bill Lear","Alex Riesen","Johannes Schindelin","Linus Torvalds","Karl Hasselström","Bart Trojanowski","Andy Parkins","Matthieu Moy","Michael Poole","Martin Langhoff","Theodore Tso","Junio C Hamano","Jakub Narebski","Sergio Callegari"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"36008","messageId":"17895.18265.710811.536526@lisa.zopyra.com","threadId":"7042","inReplyTo":null,"subject":"Git checkout preserve timestamp?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-01T21:36:25Z","receivedAt":"2007-03-01T21:36:25Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"I often find myself in branch A, with everything checked in and\ncompiled, wanting to look at something on branch B. I hop to branch\nB, look, and come back to branch A. Unfortunately, when I then do a\nmake, files that differed between A and B will be recompiled, as well as\nany further dependencies.\n\nI wonder if it would be possible or desirable to have a config flag\nthat told git to restore the timestamps across branch checkouts in\norder to prevent this perturbation.\n\nSo, when git does a checkout of a branch, it would look to see which\nfiles in the current branch are changed, tuck away the timestamps for\nthose, and switch to the new branch. On return to the former, the\nsame would be done for the new branch, then after the changed files\nwere restored, the timestamps would be reset.\n\nOne thing this would enable is to be able to hold the compilation\nproducts of multiple branches at the same time in the same working\ntree, switch back and forth between branches, and only have to compile\ncode that you actually modify. Currently, we store compilation\nproducts in a directory that is composed of the architecture, compiler,\ncompiler options, and so forth, among which also could be the branch\nname.\n\nAnyway, just an idea I thought worth batting about.\n\n\nBill\n"},{"id":"36011","messageId":"81b0412b0703011348q7f3e71f3qb1f207178c496668@mail.gmail.com","threadId":"7042","inReplyTo":"17895.18265.710811.536526@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-03-01T21:48:39Z","receivedAt":"2007-03-01T21:48:39Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 3/1/07, Bill Lear wrote:\n> I wonder if it would be possible or desirable to have a config flag\n> that told git to restore the timestamps across branch checkouts in\n> order to prevent this perturbation.\n\nAlmost every SCM has such a flag. And every one of them warn\nagainst using it.\n\n> So, when git does a checkout of a branch, it would look to see which\n> files in the current branch are changed, tuck away the timestamps for\n> those, and switch to the new branch. On return to the former, the\n> same would be done for the new branch, then after the changed files\n> were restored, the timestamps would be reset.\n\nFor instance, timestamp of which machine do you want to restore?\nHow do you know if they are synchronized?\n\n> One thing this would enable is to be able to hold the compilation\n> products of multiple branches at the same time in the same working\n> tree, switch back and forth between branches, and only have to compile\n> code that you actually modify. Currently, we store compilation\n> products in a directory that is composed of the architecture, compiler,\n> compiler options, and so forth, among which also could be the branch\n> name.\n\nUsually, you will just screw up the build process beyond all repair.\n\n> Anyway, just an idea I thought worth batting about.\n\nConsider separating build and working repositories.\nMerge things into build repo, switch the branches\nfreely in your working repo. Works just fine for me.\n"},{"id":"36016","messageId":"Pine.LNX.4.63.0703012304200.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7042","inReplyTo":"17895.18265.710811.536526@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-01T22:13:27Z","receivedAt":"2007-03-01T22:13:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Bill,\n\nOn Thu, 1 Mar 2007, Bill Lear wrote:\n\n> I often find myself in branch A, with everything checked in and \n> compiled, wanting to look at something on branch B.\n\nI did that, too, until git-show learnt about the nice \":\" syntax.\n\nFor example, if I want to know what is in branch B, I do\n\n\t$ git show B:\n\nwhich shows the root directory of the revision \"B\" (this is in line with \n: if you interpret \"\" as the root path). The subtrees \nare all identified by trailing slashes. Then you can say\n\n\t$ git show B:Documentation/Makefile\n\nIf you want to know the differences to the file \"doc/GNUMakefile\" in your \ncurrent working tree, do\n\n\t$ git diff B:Documentation/Makefile -- doc/GNUMakefile\n\nNo need to switch branches.\n\nAnd if you _do_ need to switch branches, why not make a local clone, \nsharing the object database:\n\n\t$ git clone -l -s . test-directory\n\nThis is _very_ fast, since it basically checks out the branches in \ntest-directory/. Right now, you have to go to the test-directory, and \nswitch the branches manually (I think), but talk has been that you may be \nable to tell git-clone which branch you really want.\n\nHth,\nDscho\n"},{"id":"36018","messageId":"Pine.LNX.4.64.0703011409220.12485@woody.linux-foundation.org","threadId":"7042","inReplyTo":"17895.18265.710811.536526@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-01T22:25:56Z","receivedAt":"2007-03-01T22:25:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 1 Mar 2007, Bill Lear wrote:\n>\n> I often find myself in branch A, with everything checked in and\n> compiled, wanting to look at something on branch B. I hop to branch\n> B, look, and come back to branch A. Unfortunately, when I then do a\n> make, files that differed between A and B will be recompiled, as well as\n> any further dependencies.\n> \n> I wonder if it would be possible or desirable to have a config flag\n> that told git to restore the timestamps across branch checkouts in\n> order to prevent this perturbation.\n\nI think you're much better off just using multiple repositories instead, \nif this is something common.\n\nMessing with timestamps is not going to work in general. It's just going \nto guarantee you that \"make\" gets confused in a really bad way, and does \nnot recompile *enough* instead of recompiling *too much*.\n\nGit does make it possible to do your \"check the other branch out\" thing \nvery easily, in many different ways.\n\nYou could create some trivial script that does any of the following \n(ranging from the trivial to the more exotic):\n\n - just create a new repo:\n\n\tgit clone old new\n\tcd new\n\tgit checkout origin/\n\n and there you are. The old timestamps are fine in your old repo, and \n you can work (and compile) in the new one, without affectign the old \n one at all.\n\n Use the flags \"-n -l -s\" to \"git clone\" to basically make this \n instantaneous. For lots of files (eg big repos like the kernel), it's \n not going to be as fast as just switching branches, but havign a second \n copy of the working tree can be quite powerful.\n\n - do the same thing with just a tar-ball instead, if you want to\n\n\tgit archive --format=tar --prefix=new-tree/ |\n\t\t(cd .. ; tar xvf -)\n\n which is really quite fast, if you just want a snapshot.\n\n - get used to \"git show\", and just look at individual files.\n\n This is actually *really* useful at times. You just do\n\n\tgit show otherbranch:filename\n\n in one xterm window, and look at the same file in your current branch \n in another window. In particular, this should be trivial to do with \n scriptable editors (ie GNU emacs), where it should be possible to \n basically have a whole \"dired mode\" for other branches within the \n editor, using this. For all I know, the emacs git mode already offers \n something like this (I'm not an emacs user)\n\n - and in the extreme example of that \"virtual directory\" thing, there was \n at least somebody working on a git plugin for FUSE, ie you could \n literally just have virtual directories showing *all* your branches.\n\nand I'm sure any of the above are better alternatives than playing games \nwith file timestamps.\n\n\t\tLinus\n"},{"id":"36019","messageId":"Pine.LNX.4.63.0703012330480.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7042","inReplyTo":"Pine.LNX.4.64.0703011409220.12485@woody.linux-foundation.org","subject":"Re: Git checkout preserve timestamp?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-01T22:32:10Z","receivedAt":"2007-03-01T22:32:10Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 1 Mar 2007, Linus Torvalds wrote:\n\n> - and in the extreme example of that \"virtual directory\" thing, there \n> was at least somebody working on a git plugin for FUSE, ie you could\n> literally just have virtual directories showing *all* your branches.\n\nYou mean http://www.sfgoth.com/~mitch/linux/gitfs/? Funny, it came up on \nIRC a few days ago. gitster said he'd issue \"mkdir\" instead of \"git \ncheckout -b\" by mistake somtimes...\n\nCiao,\nDscho\n"},{"id":"36052","messageId":"20070302091426.GA2605@diana.vm.bytemark.co.uk","threadId":"7042","inReplyTo":"17895.18265.710811.536526@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-03-02T09:14:26Z","receivedAt":"2007-03-02T09:14:26Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-03-01 15:36:25 -0600, Bill Lear wrote:\n\n> I often find myself in branch A, with everything checked in and\n> compiled, wanting to look at something on branch B. I hop to branch\n> B, look, and come back to branch A. Unfortunately, when I then do a\n> make, files that differed between A and B will be recompiled, as\n> well as any further dependencies.\n\nLike others have already recommended, I usually just use separate\nrepositories to work around this problem. Of course, the proper fix is\nto use a make-like tool that uses content hashes as well as timestamps\nto decide if a file has been updated ...\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"36085","messageId":"17896.9631.316001.869157@lisa.zopyra.com","threadId":"7042","inReplyTo":"20070302091426.GA2605@diana.vm.bytemark.co.uk","subject":"Re: Git checkout preserve timestamp?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-02T13:24:47Z","receivedAt":"2007-03-02T13:24:47Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Friday, March 2, 2007 at 10:14:26 (+0100) Karl Hasselström writes:\n> .... Of course, the proper fix is\n>to use a make-like tool that uses content hashes as well as timestamps\n>to decide if a file has been updated ...\n\nI like this idea...\n\n\nBill\n"},{"id":"36093","messageId":"20070302150125.GF7671@jukie.net","threadId":"7042","inReplyTo":"17896.9631.316001.869157@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Bart Trojanowski","fromEmail":"bart@jukie.net","sentAt":"2007-03-02T15:01:25Z","receivedAt":"2007-03-02T15:01:25Z","isPatch":false,"sender":{"key":"bart@jukie.net","avatar":"https://avatars.githubusercontent.com/u/6721?v=4"},"body":"* Bill Lear [070302 08:28]:\n> On Friday, March 2, 2007 at 10:14:26 (+0100) Karl Hasselström writes:\n> > .... Of course, the proper fix is\n> >to use a make-like tool that uses content hashes as well as timestamps\n> >to decide if a file has been updated ...\n> \n> I like this idea...\n\nIf the content is C, you can use ccache. Which is pretty close to the\n\"proper fix\".\n\n-Bart\n\n-- \n\t\t\t\tWebSig: http://www.jukie.net/~bart/sig/\n"},{"id":"36095","messageId":"Pine.LNX.4.63.0703021618000.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7042","inReplyTo":"17896.9631.316001.869157@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-02T15:18:41Z","receivedAt":"2007-03-02T15:18:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 2 Mar 2007, Bill Lear wrote:\n\n> On Friday, March 2, 2007 at 10:14:26 (+0100) Karl Hasselström writes:\n> > .... Of course, the proper fix is\n> >to use a make-like tool that uses content hashes as well as timestamps\n> >to decide if a file has been updated ...\n> \n> I like this idea...\n\nI don't like it at all. The proper fix is to _not_ change the contents of \nthe current working directory, if you don't want to change them to begin \nwith.\n\nCiao,\nDscho\n"},{"id":"36105","messageId":"20070302162136.GA9593@diana.vm.bytemark.co.uk","threadId":"7042","inReplyTo":"Pine.LNX.4.63.0703021618000.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git checkout preserve timestamp?","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-03-02T16:21:36Z","receivedAt":"2007-03-02T16:21:36Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-03-02 16:18:41 +0100, Johannes Schindelin wrote:\n\n> On Fri, 2 Mar 2007, Bill Lear wrote:\n>\n> > On Friday, March 2, 2007 at 10:14:26 (+0100) Karl Hasselström\n> > writes:\n>\n> > > Of course, the proper fix is to use a make-like tool that uses\n> > > content hashes as well as timestamps to decide if a file has\n> > > been updated ...\n> >\n> > I like this idea...\n>\n> I don't like it at all. The proper fix is to _not_ change the\n> contents of the current working directory, if you don't want to\n> change them to begin with.\n\nWell, in a sense, yes. Not overwriting the current state when all you\nwant to do is peek at some other state is obviously the better fix of\nthe two.\n\nHowever, given that your file timestamps have been bumped (without\nfile content changes), it's a performance bug in your make tool if\nthis causes it to needlessly rebuild half the known universe. (Fixing\nthe bug by using content hashes to detect changes may or may not be a\ngood trade-off, depending on your workflow.)\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"36117","messageId":"Pine.LNX.4.63.0703022018190.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7042","inReplyTo":"20070302162136.GA9593@diana.vm.bytemark.co.uk","subject":"Re: Git checkout preserve timestamp?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-02T19:21:17Z","receivedAt":"2007-03-02T19:21:17Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 2 Mar 2007, Karl Hasselström wrote:\n\n> However, given that your file timestamps have been bumped (without file \n> content changes),\n\nThere were changes. Only that they have been taken back, but that is \n_another_ change.\n\n> it's a performance bug in your make tool if this causes it to needlessly \n> rebuild half the known universe. (Fixing the bug by using content hashes \n> to detect changes may or may not be a good trade-off, depending on your \n> workflow.)\n\nGetting dependencies right is sometimes not very easy. I participate in \nprojects which have _seriously_ broken dependencies. In these cases, I do \na quick \"touch source.c\" to force a recompilation.\n\nYou'd break this workaround.\n\nCiao,\nDscho\n\nP.S.: yes, I know I could possibly find the object file and remove that, \ntoo. But finding the source is often easier.\n"},{"id":"36283","messageId":"20070305072323.GA31169@diana.vm.bytemark.co.uk","threadId":"7042","inReplyTo":"Pine.LNX.4.63.0703022018190.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git checkout preserve timestamp?","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-03-05T07:23:23Z","receivedAt":"2007-03-05T07:23:23Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-03-02 20:21:17 +0100, Johannes Schindelin wrote:\n\n> On Fri, 2 Mar 2007, Karl Hasselström wrote:\n>\n> > However, given that your file timestamps have been bumped (without\n> > file content changes),\n>\n> There were changes. Only that they have been taken back, but that is\n> _another_ change.\n\nSince the content is exactly the same as before, I'd be of the strong\nopinion that nothing has changed as far as the make system should be\nconcerned. But this is getting off-topic, so I'll just agree to\ndisagree if you do. :-)\n\n> > it's a performance bug in your make tool if this causes it to\n> > needlessly rebuild half the known universe. (Fixing the bug by\n> > using content hashes to detect changes may or may not be a good\n> > trade-off, depending on your workflow.)\n>\n> Getting dependencies right is sometimes not very easy. I participate\n> in projects which have _seriously_ broken dependencies. In these\n> cases, I do a quick \"touch source.c\" to force a recompilation.\n>\n> You'd break this workaround.\n>\n> P.S.: yes, I know I could possibly find the object file and remove\n> that, too. But finding the source is often easier.\n\nWell, all you'd need is a way to tell the make system to flush its\ncaches for source.c (or some larger portion of the build, as\nnecessary). Such as \"make-tool --flush-cache source.c\".\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"36316","messageId":"Pine.LNX.4.63.0703051230390.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7042","inReplyTo":"20070305072323.GA31169@diana.vm.bytemark.co.uk","subject":"Re: Git checkout preserve timestamp?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-05T11:32:07Z","receivedAt":"2007-03-05T11:32:07Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Mar 2007, Karl Hasselström wrote:\n\n> On 2007-03-02 20:21:17 +0100, Johannes Schindelin wrote:\n> \n> > On Fri, 2 Mar 2007, Karl Hasselström wrote:\n> >\n> > > However, given that your file timestamps have been bumped (without\n> > > file content changes),\n> >\n> > There were changes. Only that they have been taken back, but that is\n> > _another_ change.\n> \n> Since the content is exactly the same as before, I'd be of the strong\n> opinion that nothing has changed as far as the make system should be\n> concerned.\n\nYou are missing an important point here: there _was_ a change.\n\nCiao,\nDscho\n"},{"id":"36317","messageId":"200703051213.52513.andyparkins@gmail.com","threadId":"7042","inReplyTo":"20070302162136.GA9593@diana.vm.bytemark.co.uk","subject":"Re: Git checkout preserve timestamp?","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-05T12:13:50Z","receivedAt":"2007-03-05T12:13:50Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Friday 2007 March 02 16:21, Karl Hasselström wrote:\n\n> However, given that your file timestamps have been bumped (without\n> file content changes), it's a performance bug in your make tool if\n\nActually, git is as good as it could reasonably get in this regard.\n\nLet's say you did this:\n\n git checkout branch1\n git checkout branch2\n git checkout branch1\n\nGit will only touch the timestamps of files that are different between the \nbranches. If the same file is in both branches, then that one remains \nuntouched in your working tree (it's tricks like this that make git so \nblindingly fast).\n\nThe fact that you've changed back from branch2 to branch1 is the bone of \ncontention - how is git meant to know that you haven't done a compilation \nwhile you were on branch2 and hence changed the files that untracked files \ndepend on? The /only/ sane thing it can do is, in both cases, update changed \nfiles to have the current time.\n\nPerhaps an example would make it clearer:\n\n git checkout branch1\n # sourcefile.c changes, so git touches the timestamp\n # make would rebuild sourcefile.o\n git checkout branch2\n # sourcefile.c changes, so git touches the timestamp\n # make would rebuild sourcefile.o\n git checkout branch1\n # sourcefile.c changes, so git touches the timestamp\n # make would rebuild sourcefile.o\n\nThat's all exactly right, make knows in each case the the \".o\" file is out of \ndate because it has a timestamp earlier than sourcefile.c\n\nNow take the suggestion that timestamps from the repository version should be \nrestored and do the same thing:\n\n git checkout branch1\n # sourcefile.c changes, git sets the timestamp to $timestamp1\n # make would rebuild sourcefile.o (setting its timestamp to $now)\n git checkout branch2\n # sourcefile.c changes, so sets the timestamp to $timestamp2\n # make wouldn't rebuild sourcefile.o because $timestamp2 < $now\n git checkout branch1\n # sourcefile.c changes, so git sets the timestamp to $timestamp1\n # make wouldn't rebuild sourcefile.o because $timestamp1 < $now\n\nAll very wrong; in two out of the three builds, the wrong sourcefile.o ends up \nin the final object.\n\nWhat git does now is absolutely the right thing. It keeps unnecessary \nrebuilds to the safest minimum.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"36319","messageId":"20070305122828.GA3481@diana.vm.bytemark.co.uk","threadId":"7042","inReplyTo":"Pine.LNX.4.63.0703051230390.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git checkout preserve timestamp?","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-03-05T12:28:28Z","receivedAt":"2007-03-05T12:28:28Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-03-05 12:32:07 +0100, Johannes Schindelin wrote:\n\n> On Mon, 5 Mar 2007, Karl Hasselström wrote:\n>\n> > Since the content is exactly the same as before, I'd be of the\n> > strong opinion that nothing has changed as far as the make system\n> > should be concerned.\n>\n> You are missing an important point here: there _was_ a change.\n\nBut I don't want my make tool to care! I want it to rebuild if and\nonly if the file contents now are different from the file contents as\nof the last rebuild.\n\nJust like if I change a git-tracked file, then change it back, git\nwill _not_ claim that the file has changed; it will compute its sha1,\nsee that it is identical to what's in HEAD, and from there on consider\nthat file not changed even thogh its timestamp was changed.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"36320","messageId":"20070305123348.GB3481@diana.vm.bytemark.co.uk","threadId":"7042","inReplyTo":"200703051213.52513.andyparkins@gmail.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-03-05T12:33:48Z","receivedAt":"2007-03-05T12:33:48Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-03-05 12:13:50 +0000, Andy Parkins wrote:\n\n> On Friday 2007 March 02 16:21, Karl Hasselström wrote:\n>\n> > However, given that your file timestamps have been bumped (without\n> > file content changes), it's a performance bug in your make tool if\n>\n> Actually, git is as good as it could reasonably get in this regard.\n\nI know.\n\n> Let's say you did this:\n>\n> git checkout branch1\n> git checkout branch2\n> git checkout branch1\n>\n> Git will only touch the timestamps of files that are different\n> between the branches.\n\nYes.\n\n> The fact that you've changed back from branch2 to branch1 is the\n> bone of contention - how is git meant to know that you haven't done\n> a compilation while you were on branch2 and hence changed the files\n> that untracked files depend on? The /only/ sane thing it can do is,\n> in both cases, update changed files to have the current time.\n\nYes, that's the only sane thing.\n\nMy point isn't that _git_ should know that I haven't compiled stuff.\nMy point is that my make tool should realize that even though the\nfile's timestamp has changed since last rebuild, the contents haven't\nchanged (or, to be precise, they're identical to what they were), and\nso there's no need to rebuild.\n\nNow, obviously \"make\" isn't such a make tool, since it goes only by\ntimestamps.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"36321","messageId":"200703051319.17046.andyparkins@gmail.com","threadId":"7042","inReplyTo":"20070305123348.GB3481@diana.vm.bytemark.co.uk","subject":"Re: Git checkout preserve timestamp?","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-05T13:19:15Z","receivedAt":"2007-03-05T13:19:15Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007 March 05 12:33, Karl Hasselström wrote:\n\n> Now, obviously \"make\" isn't such a make tool, since it goes only by\n> timestamps.\n\nPerhaps this will help you:\n\nhttp://kolpackov.net/pipermail/notes/2004-September/000011.html\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"36323","messageId":"17900.11612.872928.633406@lisa.zopyra.com","threadId":"7042","inReplyTo":"200703051213.52513.andyparkins@gmail.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-05T14:46:52Z","receivedAt":"2007-03-05T14:46:52Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Monday, March 5, 2007 at 12:13:50 (+0000) Andy Parkins writes:\n>...\n>Now take the suggestion that timestamps from the repository version should be \n>restored and do the same thing:\n>\n> git checkout branch1\n> # sourcefile.c changes, git sets the timestamp to $timestamp1\n> # make would rebuild sourcefile.o (setting its timestamp to $now)\n> git checkout branch2\n> # sourcefile.c changes, so sets the timestamp to $timestamp2\n> # make wouldn't rebuild sourcefile.o because $timestamp2 < $now\n> git checkout branch1\n> # sourcefile.c changes, so git sets the timestamp to $timestamp1\n> # make wouldn't rebuild sourcefile.o because $timestamp1 < $now\n>\n>All very wrong; in two out of the three builds, the wrong\n>sourcefile.o ends up in the final object.\n\nAll very wrong if you ignore what I wrote as part of my original note:\nkeep compilation products separated by branch name, not in the same\nplace. This is essential to my request: without it, it is indeed very\nwrong. We currently separate out by compiler, options, machine\narchitecture, and adding the branch to that is trivial.\n\n\nBill\n"},{"id":"36325","messageId":"20070305145347.GC3481@diana.vm.bytemark.co.uk","threadId":"7042","inReplyTo":"200703051319.17046.andyparkins@gmail.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2007-03-05T14:53:47Z","receivedAt":"2007-03-05T14:53:47Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2007-03-05 13:19:15 +0000, Andy Parkins wrote:\n\n> On Monday 2007 March 05 12:33, Karl Hasselström wrote:\n>\n> > Now, obviously \"make\" isn't such a make tool, since it goes only\n> > by timestamps.\n>\n> Perhaps this will help you:\n>\n> http://kolpackov.net/pipermail/notes/2004-September/000011.html\n\nThanks for the pointer; I hadn't seen that technique before. But it\nisn't really worth it. The make tool going by hash rather than\ntimestamp is a nice-to-have, not a must-have (for those projects I've\nbeen involved in anyway), so the cost of the solution proposed in that\nmessage is too high.\n\n-- \nKarl Hasselström, kha@treskal.com\n www.treskal.com/kalle\n"},{"id":"36334","messageId":"200703051601.49370.andyparkins@gmail.com","threadId":"7042","inReplyTo":"17900.11612.872928.633406@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-03-05T16:01:45Z","receivedAt":"2007-03-05T16:01:45Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007 March 05 14:46, Bill Lear wrote:\n\n> All very wrong if you ignore what I wrote as part of my original note:\n> keep compilation products separated by branch name, not in the same\n\nI realise why it's causing you troubles. However, I was hoping that that \nlittle example shows why it can never be right to use the timestamp out of \nthe repository.\n\n> place. This is essential to my request: without it, it is indeed very\n> wrong. We currently separate out by compiler, options, machine\n> architecture, and adding the branch to that is trivial.\n\nI'm afraid that the unnecessary recompile is just a by-product of that \norganisation. I still say that git is correct to touch the file dates.\n\n[blatent plug]: perhaps my poorman's submodule support will get you by until \nreal submodule support is implemented?\n\nhttp://lists.zerezo.com/git/msg334639.html\n\nI doubt it though - as you would probably want automatic checkout in your \nsituation.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"36337","messageId":"17900.17736.918538.734811@lisa.zopyra.com","threadId":"7042","inReplyTo":"200703051601.49370.andyparkins@gmail.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-05T16:28:56Z","receivedAt":"2007-03-05T16:28:56Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Monday, March 5, 2007 at 16:01:45 (+0000) Andy Parkins writes:\n>On Monday 2007 March 05 14:46, Bill Lear wrote:\n>\n>> All very wrong if you ignore what I wrote as part of my original note:\n>> keep compilation products separated by branch name, not in the same\n>\n>I realise why it's causing you troubles. However, I was hoping that that \n>little example shows why it can never be right to use the timestamp out of \n>the repository.\n\nI don't understand then. If the timestamp is stored per-branch, as it\nmust be, then no effective change takes place whatsoever, and all\nproducts are compiled properly, and in their proper place.\n\nIf master:source.c compiles to .master/source.o and has a timestamp\n.master/source.c.timestamp, switching to branch1 and back, and\nrestoring the timestamp does not do anything wrong. It just prevents\na recompilation.\n\n>I'm afraid that the unnecessary recompile is just a by-product of that \n>organisation. I still say that git is correct to touch the file dates.\n\nWell, git is certainly correct for those who want the standard behavior.\n\nI don't think the current submodule support will help, but I am keen\nto see submodules for other reasons.\n\n\nBill\n"},{"id":"36353","messageId":"17900.27067.247950.419438@lisa.zopyra.com","threadId":"7042","inReplyTo":"Pine.LNX.4.63.0703051230390.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git checkout preserve timestamp?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-05T19:04:27Z","receivedAt":"2007-03-05T19:04:27Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Monday, March 5, 2007 at 12:32:07 (+0100) Johannes Schindelin writes:\n>Hi,\n>\n>On Mon, 5 Mar 2007, Karl Hasselström wrote:\n>\n>> On 2007-03-02 20:21:17 +0100, Johannes Schindelin wrote:\n>> \n>> > On Fri, 2 Mar 2007, Karl Hasselström wrote:\n>> >\n>> > > However, given that your file timestamps have been bumped (without\n>> > > file content changes),\n>> >\n>> > There were changes. Only that they have been taken back, but that is\n>> > _another_ change.\n>> \n>> Since the content is exactly the same as before, I'd be of the strong\n>> opinion that nothing has changed as far as the make system should be\n>> concerned.\n>\n>You are missing an important point here: there _was_ a change.\n\nPhysically, yes, the bits were changed, but logically nothing has\nchanged, at least in the scenario I outlined.\n\n\nBill\n"},{"id":"36354","messageId":"Pine.LNX.4.63.0703052014020.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7042","inReplyTo":"17900.27067.247950.419438@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-05T19:16:35Z","receivedAt":"2007-03-05T19:16:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Mar 2007, Bill Lear wrote:\n\n> On Monday, March 5, 2007 at 12:32:07 (+0100) Johannes Schindelin writes:\n>\n> >On Mon, 5 Mar 2007, Karl Hasselström wrote:\n> >\n> >> On 2007-03-02 20:21:17 +0100, Johannes Schindelin wrote:\n> >> \n> >> > On Fri, 2 Mar 2007, Karl Hasselström wrote:\n> >> >\n> >> > > However, given that your file timestamps have been bumped (without\n> >> > > file content changes),\n> >> >\n> >> > There were changes. Only that they have been taken back, but that is\n> >> > _another_ change.\n> >> \n> >> Since the content is exactly the same as before, I'd be of the strong\n> >> opinion that nothing has changed as far as the make system should be\n> >> concerned.\n> >\n> >You are missing an important point here: there _was_ a change.\n> \n> Physically, yes, the bits were changed,\n\nYeah, I know people, who would like to change laws of physics, too.\n\n> but logically nothing has changed, at least in the scenario I outlined.\n\nBut it could! Even in the scenario you outlined. If somebody (might be \neven you yourself) pushes into your repo, under the name of the branch to \nwhich you switch back to right after that. Bingo. Files changed.\n\nSee? That is what happens if you don't fix things the right way, you keep \ngetting problems. Yes, you can solve them in another tacky way, but you'll \nonly get different problems, then.\n\nCiao,\nDscho\n"},{"id":"36359","messageId":"17900.30394.172067.743310@lisa.zopyra.com","threadId":"7042","inReplyTo":"Pine.LNX.4.63.0703052014020.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git checkout preserve timestamp?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-05T19:59:54Z","receivedAt":"2007-03-05T19:59:54Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Monday, March 5, 2007 at 20:16:35 (+0100) Johannes Schindelin writes:\n>Hi,\n>\n>On Mon, 5 Mar 2007, Bill Lear wrote:\n>\n>> On Monday, March 5, 2007 at 12:32:07 (+0100) Johannes Schindelin writes:\n>>\n>> >On Mon, 5 Mar 2007, Karl Hasselström wrote:\n>> >\n>> >> On 2007-03-02 20:21:17 +0100, Johannes Schindelin wrote:\n>> >> \n>> >> > On Fri, 2 Mar 2007, Karl Hasselström wrote:\n>> >> >\n>> >> > > However, given that your file timestamps have been bumped (without\n>> >> > > file content changes),\n>> >> >\n>> >> > There were changes. Only that they have been taken back, but that is\n>> >> > _another_ change.\n>> >> \n>> >> Since the content is exactly the same as before, I'd be of the strong\n>> >> opinion that nothing has changed as far as the make system should be\n>> >> concerned.\n>> >\n>> >You are missing an important point here: there _was_ a change.\n>> \n>> Physically, yes, the bits were changed,\n>\n>Yeah, I know people, who would like to change laws of physics, too.\n>\n>> but logically nothing has changed, at least in the scenario I outlined.\n>\n>But it could! Even in the scenario you outlined. If somebody (might be \n>even you yourself) pushes into your repo, under the name of the branch to \n>which you switch back to right after that. Bingo. Files changed.\n\nYes, they change, and so would the timestamp. So what?\n\n>See? That is what happens if you don't fix things the right way, you keep \n>getting problems. Yes, you can solve them in another tacky way, but you'll \n>only get different problems, then.\n\nI never said git was \"broken\". I describe a usage scenario I would\npersonally find useful.\n\n\nBill\n"},{"id":"36363","messageId":"Pine.LNX.4.63.0703052143120.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7042","inReplyTo":"17900.30394.172067.743310@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-05T20:44:26Z","receivedAt":"2007-03-05T20:44:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Mar 2007, Bill Lear wrote:\n\n> On Monday, March 5, 2007 at 20:16:35 (+0100) Johannes Schindelin writes:\n>\n> >If somebody (might be even you yourself) pushes into your repo, under \n> >the name of the branch to which you switch back to right after that. \n> >Bingo. Files changed.\n> \n> Yes, they change, and so would the timestamp. So what?\n\nThink about it. Why would the timestamp change? Because Git wrote the \nfile? But that was exactly the behaviour you were complaining about.\n\nCiao,\nDscho\n"},{"id":"36369","messageId":"17900.36569.805689.922989@lisa.zopyra.com","threadId":"7042","inReplyTo":"Pine.LNX.4.63.0703052143120.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git checkout preserve timestamp?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-05T21:42:49Z","receivedAt":"2007-03-05T21:42:49Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Monday, March 5, 2007 at 21:44:26 (+0100) Johannes Schindelin writes:\n>Hi,\n>\n>On Mon, 5 Mar 2007, Bill Lear wrote:\n>\n>> On Monday, March 5, 2007 at 20:16:35 (+0100) Johannes Schindelin writes:\n>>\n>> >If somebody (might be even you yourself) pushes into your repo, under \n>> >the name of the branch to which you switch back to right after that. \n>> >Bingo. Files changed.\n>> \n>> Yes, they change, and so would the timestamp. So what?\n>\n>Think about it. Why would the timestamp change? Because Git wrote the \n>file? But that was exactly the behaviour you were complaining about.\n\nNot because git wrote the file, but because git notices that content\nchanges, and writes the file (and timestamps it) \"smartly\". If\nsomeone writes into the repo, the timestamp stored becomes invalidated\nand the write of the file just creates the timestamp at the time of\nthe checkout. If no write into the repo index occurs, the stored\ntimestamp is applied after the file is checked out.\n\n\nBill\n"},{"id":"36370","messageId":"Pine.LNX.4.64.0703051347490.3998@woody.linux-foundation.org","threadId":"7042","inReplyTo":"17900.36569.805689.922989@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-05T21:50:45Z","receivedAt":"2007-03-05T21:50:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 5 Mar 2007, Bill Lear wrote:\n> \n> Not because git wrote the file, but because git notices that content\n> changes, and writes the file (and timestamps it) \"smartly\". If\n> someone writes into the repo, the timestamp stored becomes invalidated\n> and the write of the file just creates the timestamp at the time of\n> the checkout. If no write into the repo index occurs, the stored\n> timestamp is applied after the file is checked out.\n\nBut Bill, don't you realize that restoring the timestamp is *WRONG*?\n\nThere's no way that git can know whether you did a \"make\" in between \nswitching back and forth between branches. That's true on a very \nfundamental level, but it's doubly true when anybody uses a separate \nobject directory (which doesn't leave any information *at*all* in the \nsource tree about the fact that somebody did a \"make\").\n\nSo stop even asking for this. We'd have to be totally and utterly \nincompetent to do what you ask for. We're simply not that stupid. \n\nWe already pointed out how you can do what you want to do *other* ways \nthat are *not* idiotic and incompetent. I don't think you even answered.\n\n\t\t\tLinus\n"},{"id":"36371","messageId":"Pine.LNX.4.63.0703052301160.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7042","inReplyTo":"17900.36569.805689.922989@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-05T22:02:04Z","receivedAt":"2007-03-05T22:02:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Mar 2007, Bill Lear wrote:\n\n> Not because git wrote the file, but because git notices that content\n> changes, and writes the file (and timestamps it) \"smartly\".\n\nYou know why you put that in quotes? I know. Because it is not smart to do \nthat.\n\nCiao,\nDscho\n"},{"id":"36372","messageId":"vpqps7ngxfb.fsf@olympe.imag.fr","threadId":"7042","inReplyTo":"Pine.LNX.4.64.0703051347490.3998@woody.linux-foundation.org","subject":"Re: Git checkout preserve timestamp?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-03-05T22:03:52Z","receivedAt":"2007-03-05T22:03:52Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Linus Torvalds writes:\n\n> We already pointed out how you can do what you want to do *other* ways \n> that are *not* idiotic and incompetent. I don't think you even answered.\n\nIn particular, \"ccache\" which has precisely been designed for this\nkind of situation, cited above.\n\n-- \nMatthieu\n"},{"id":"36374","messageId":"17900.39124.763603.695942@lisa.zopyra.com","threadId":"7042","inReplyTo":"Pine.LNX.4.64.0703051347490.3998@woody.linux-foundation.org","subject":"Re: Git checkout preserve timestamp?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-05T22:25:24Z","receivedAt":"2007-03-05T22:25:24Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Monday, March 5, 2007 at 13:50:45 (-0800) Linus Torvalds writes:\n>On Mon, 5 Mar 2007, Bill Lear wrote:\n>> \n>> Not because git wrote the file, but because git notices that content\n>> changes, and writes the file (and timestamps it) \"smartly\". If\n>> someone writes into the repo, the timestamp stored becomes invalidated\n>> and the write of the file just creates the timestamp at the time of\n>> the checkout. If no write into the repo index occurs, the stored\n>> timestamp is applied after the file is checked out.\n>\n>But Bill, don't you realize that restoring the timestamp is *WRONG*?\n\nMaybe, maybe not. Each argument I've seen doesn't convince me. Sure,\nit may be MESSY. It may be UGLY, and therefore undesirable, but I\ndon't think any of the arguments have conclusively shown that it\nis WRONG or INFEASIBLE in any way.\n\n>There's no way that git can know whether you did a \"make\" in between \n>switching back and forth between branches. ...\n\nWhy should I care whether git knows this? I never said it should. As\nI said, if I have make products in separate, per-branch directories (a\nminor extension to my current make system), I don't see how this would\nbe confusing in the least. Git should only care if the content of the\nfile in the index changes. It shouldn't care in the least about my\nmake products.\n\n> .... That's true on a very \n>fundamental level, but it's doubly true when anybody uses a separate \n>object directory (which doesn't leave any information *at*all* in the \n>source tree about the fact that somebody did a \"make\").\n\nHere's the flow. Perhaps I'm fundamentally confused, and I'll be\nthe first to admit that is true in plenty of ways:\n\nI edit sourcefile.c, compile it, then commit it with\nN=timestamp(sourcefile.c) on master. N is <\ntimestamp(.master/sourcefile.o). I then switch to branchX. N is\nstored by git for master:sourcefile.c. No stored timestamp are on\nthis branch, so the file gets the timestamp it gets on checkout\nM=timestamp(sourcefile.c). I compile the file again, all is well. I\nmove back to master branch. Git stores M as branchX:sourcefile.c Git\nchecks out the file, and stamps it with N. I do a make. No\nrecompilation happens. I switch back to branchX, the file is checked\nout and stamped with timestamp M. I do a make. No recompilation\nhappens. Happy happy, joy joy. If someone pushes into my repo,\nas Johannes suggested (how that would work, being a non-bare\nrepo, is beyond me, but whatever), the timestamp for that file\non that branch would be invalidated, and the file would get\nwhatever timestamp it got when it was written to disk.\n\nNow, all of this may be DISTASTEFUL, UGLY, POOR DESIGN, etc., but I\ndon't see how it is WRONG. As someone who has professed the motto\n\"actually useful is a lot better than clean, but not as useful\",\nI fail to see what has gotten you so exercised about this.\n\n>So stop even asking for this. We'd have to be totally and utterly \n>incompetent to do what you ask for. We're simply not that stupid. \n>\n>We already pointed out how you can do what you want to do *other* ways \n>that are *not* idiotic and incompetent. I don't think you even answered.\n\nI am not asking for this, I'm just arguing the point, waiting for a\nconvincing argument rather than having someone call me \"idiotic and\nincompetent\" and \"stupid\" for asking for it in the first place and\ncarrying on in the spirit of discovery and open learning.\n\nFor your information, I did in fact answer, politely, thanking the\nposter for pointing our hash-based \"stamps\" that could do this sort of\nthing. I downloaded the software pointed to and tried it out,\nunsuccessfully, as it will require redoing our make system (not\nthat I'm opposed to that, just that it will take time).\n\nSo ... thanks.\n\n\nBill\n"},{"id":"36375","messageId":"17900.39399.480292.979137@lisa.zopyra.com","threadId":"7042","inReplyTo":"Pine.LNX.4.63.0703052301160.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git checkout preserve timestamp?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-05T22:29:59Z","receivedAt":"2007-03-05T22:29:59Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Monday, March 5, 2007 at 23:02:04 (+0100) Johannes Schindelin writes:\n>On Mon, 5 Mar 2007, Bill Lear wrote:\n>> Not because git wrote the file, but because git notices that content\n>> changes, and writes the file (and timestamps it) \"smartly\".\n>\n>You know why you put that in quotes? I know. Because it is not smart to do \n>that.\n\nThe tone on this list is usually pretty civil, and I have benefited a\nlot from the discussions here, and greatly appreciate the effort put\nin by all concerned, but this sort of tone --- implying that I am\nstupid to even query about this --- is really not very helpful, and\nquite rude and childish.\n\n\nBill\n"},{"id":"36376","messageId":"Pine.LNX.4.64.0703051431130.3998@woody.linux-foundation.org","threadId":"7042","inReplyTo":"17900.39124.763603.695942@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-05T22:37:15Z","receivedAt":"2007-03-05T22:37:15Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 5 Mar 2007, Bill Lear wrote:\n>\n> Maybe, maybe not. Each argument I've seen doesn't convince me. Sure,\n> it may be MESSY. It may be UGLY, and therefore undesirable, but I\n> don't think any of the arguments have conclusively shown that it\n> is WRONG or INFEASIBLE in any way.\n\nI'm sorry. If you don't see how it's WRONG to seta datestamp back to \nsomething that will make a simple \"make\" *miscompile* your source tree, I \ndon't know what defintiion of \"wrong\" you are talking about.\n\nIt's WRONG. \n\nIt's STUPID.\n\nAnd it's totally INFEASIBLE to implement.\n\n> Why should I care whether git knows this? I never said it should. As\n> I said, if I have make products in separate, per-branch directories (a\n> minor extension to my current make system), I don't see how this would\n> be confusing in the least. Git should only care if the content of the\n> file in the index changes. It shouldn't care in the least about my\n> make products.\n\nBut Bill, the content in the index *does* change. It's that simple. It \nchanges every time you check out another branch. And if it doesn't change, \ngit already avoids changing mtime (because git already avoids changing the \nfile).\n\n> Here's the flow. Perhaps I'm fundamentally confused, and I'll be\n> the first to admit that is true in plenty of ways:\n> \n> I edit sourcefile.c, compile it, then commit it with\n> N=timestamp(sourcefile.c) on master. N is <\n> timestamp(.master/sourcefile.o). I then switch to branchX. N is\n> stored by git for master:sourcefile.c. No stored timestamp are on\n> this branch, so the file gets the timestamp it gets on checkout\n> M=timestamp(sourcefile.c). I compile the file again, all is well. I\n> move back to master branch. Git stores M as branchX:sourcefile.c Git\n> checks out the file, and stamps it with N. I do a make. No\n> recompilation happens.\n\nWHICH IS WRONG! You need to recompile, since the compile you did on the \nother branch DOES NOT MATCH in \"sourcefile.c\" any more. \n\nAnd if sourcefile.c _does_ match in the two branches, then git *already* \nwon't have changed it at all, so git already does the obvious \noptimization.\n\nThe thing is, \"ccache\" actually does this right. You could arguably \nintegrate ccache with more git integration, and let ccache just use the \nSHA1's that git already caches and knows about. But the real issue is that \nwhat _you_ suggest is crazy. It doesn't work.\n\n\t\tLinus\n"},{"id":"36377","messageId":"vpqirdf5n7q.fsf@olympe.imag.fr","threadId":"7042","inReplyTo":"17900.39124.763603.695942@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2007-03-05T22:39:53Z","receivedAt":"2007-03-05T22:39:53Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Bill Lear writes:\n\n> I move back to master branch. Git stores M as branchX:sourcefile.c\n> Git checks out the file, and stamps it with N. I do a make. No\n> recompilation happens.\n\nAre you not describing a situation where git would modify a file\n(\"move back to branchX\"), and no recompilation happens (whereas it\nshould)?\n\n-- \nMatthieu\n"},{"id":"36378","messageId":"Pine.LNX.4.63.0703052339050.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7042","inReplyTo":"17900.39124.763603.695942@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-05T22:56:02Z","receivedAt":"2007-03-05T22:56:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Mar 2007, Bill Lear wrote:\n\n> On Monday, March 5, 2007 at 13:50:45 (-0800) Linus Torvalds writes:\n> >On Mon, 5 Mar 2007, Bill Lear wrote:\n> >> \n> >> Not because git wrote the file, but because git notices that content\n> >> changes, and writes the file (and timestamps it) \"smartly\". If\n> >> someone writes into the repo, the timestamp stored becomes invalidated\n> >> and the write of the file just creates the timestamp at the time of\n> >> the checkout. If no write into the repo index occurs, the stored\n> >> timestamp is applied after the file is checked out.\n> >\n> >But Bill, don't you realize that restoring the timestamp is *WRONG*?\n> \n> Maybe, maybe not. Each argument I've seen doesn't convince me. Sure,\n> it may be MESSY. It may be UGLY, and therefore undesirable, but I\n> don't think any of the arguments have conclusively shown that it\n> is WRONG or INFEASIBLE in any way.\n\nIt may not be infeasible.\n\nBut it is wrong. It \"fixes\" a totallc clear idiom, namely that every time \na file is written into, the timestamp changes. And guess what, \"touch \n\" is the best proof that sometimes, you want that this happens, even \nif the content stays the same.\n\n> If someone pushes into my repo, as Johannes suggested (how that would \n> work, being a non-bare repo, is beyond me, but whatever),\n\nOf course this works. That is a fundamental feature of Git: if you strip a \nnon-bare repo of its working directory, then it becomes a bare repo.\n\n> the timestamp for that file on that branch would be invalidated, and the \n> file would get whatever timestamp it got when it was written to disk.\n\nThis approach is so fragile! It is invasive, easy to get wrong (count the \nways how to invalidate the timestamp), and serves only an obscure use \ncase, which is better solved otherwise to begin with.\n\n> >So stop even asking for this. We'd have to be totally and utterly \n> >incompetent to do what you ask for. We're simply not that stupid. \n\nFWIW I have to agree here. I saw quite a few projects go wrong, because \nmanagement insisted on abolishing a perfectly good design, just because \nthey had this pet idea.\n\n> >We already pointed out how you can do what you want to do *other* ways \n> >that are *not* idiotic and incompetent. I don't think you even \n> >answered.\n> \n> I am not asking for this, I'm just arguing the point, waiting for a\n> convincing argument rather than having someone call me \"idiotic and\n> incompetent\" and \"stupid\" for asking for it in the first place and\n> carrying on in the spirit of discovery and open learning.\n> \n> For your information, I did in fact answer, politely, thanking the\n> poster for pointing our hash-based \"stamps\" that could do this sort of\n> thing.\n\nNo. This is not what Linus was referring to (unless I am really wrong \nhere, which I refuse to believe).\n\nWe pointed out, in several ways, how much easier it is to create a \nthrow-away working directory.\n\nIt is easy, robust, and can be done _right now_ with Git.\n\nCiao,\nDscho\n"},{"id":"36382","messageId":"17900.42415.750335.329874@lisa.zopyra.com","threadId":"7042","inReplyTo":"Pine.LNX.4.64.0703051431130.3998@woody.linux-foundation.org","subject":"Re: Git checkout preserve timestamp?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-05T23:20:15Z","receivedAt":"2007-03-05T23:20:15Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Monday, March 5, 2007 at 14:37:15 (-0800) Linus Torvalds writes:\n>On Mon, 5 Mar 2007, Bill Lear wrote:\n>> I edit sourcefile.c, compile it, then commit it with\n>> N=timestamp(sourcefile.c) on master. N is <\n>> timestamp(.master/sourcefile.o). I then switch to branchX. N is\n>> stored by git for master:sourcefile.c. No stored timestamp are on\n>> this branch, so the file gets the timestamp it gets on checkout\n>> M=timestamp(sourcefile.c). I compile the file again, all is well. I\n>> move back to master branch. Git stores M as branchX:sourcefile.c Git\n>> checks out the file, and stamps it with N. I do a make. No\n>> recompilation happens.\n>\n>WHICH IS WRONG! You need to recompile, since the compile you did on the \n>other branch DOES NOT MATCH in \"sourcefile.c\" any more. \n\nWell, I'll let it drop after this, but I think you're wrong. I do NOT\nneed it to recompile when I do the third make above. The time stamps\nmatch up perfectly with the make products, the make system is NOT\nconfused, the appropriate rebuilds occurs WHEN I want them to, and my\nmake products are thereafter a model of wholesome sanity and blissful\nunity.\n\nAgain, this may be violating a sacred rule of \"thou shalt not f~ck\nwith timestamps\", but I'm not religious on that point.\n\nI share the desire of never getting make products when I should not,\nand appreciate the desire to never, ever, NOT recompile something when\nit must, which is what the above example does. I also understand\nthere are better ways than having git do this with timestamps, it's\njust that I'm not understanding your logical argument, even with all\ncaps emphasizing your points. Perhaps I'll build a prototype, have it\nblow up in my face, and then understand ...\n\n>And if sourcefile.c _does_ match in the two branches, then git *already* \n>won't have changed it at all, so git already does the obvious \n>optimization.\n\nI'll let this drop. It appears we are not communicating, which you\nseem to be translating and signaling (in all caps, no less) as \"you\nare stupid\". That's ok, I've felt that way about others from time to\ntime, so I understand and sympathize with your frustration.\n\nI do thank you (all) for pointing out the much less invasive\nalternatives, using git (right now) and still, despite this rather\nheated exchange, think git is a very cool and thoughtfully put\ntogether collection of software.\n\n\nBill\n"},{"id":"36383","messageId":"17900.42839.514960.613003@lisa.zopyra.com","threadId":"7042","inReplyTo":"Pine.LNX.4.63.0703052339050.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git checkout preserve timestamp?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-05T23:27:19Z","receivedAt":"2007-03-05T23:27:19Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Monday, March 5, 2007 at 23:56:02 (+0100) Johannes Schindelin writes:\n>...\n>It may not be infeasible.\n>\n>But it is wrong. It \"fixes\" a totallc clear idiom, ...\n\nA very valid point. I dislike breaking clear idioms also.\n\n>> the timestamp for that file on that branch would be invalidated, and the \n>> file would get whatever timestamp it got when it was written to disk.\n>\n>This approach is so fragile! It is invasive, easy to get wrong (count the \n>ways how to invalidate the timestamp), and serves only an obscure use \n>case, which is better solved otherwise to begin with.\n\nMore very valid points.\n\n>> >So stop even asking for this. We'd have to be totally and utterly \n>> >incompetent to do what you ask for. We're simply not that stupid. \n>\n>FWIW I have to agree here. I saw quite a few projects go wrong, because \n>management insisted on abolishing a perfectly good design, just because \n>they had this pet idea.\n\nThis is not my \"pet idea\". I could care less about it: I have other\nalternatives. I was just engaging in what I hoped would be a friendly\nexchange about this, but it seems to have touched a nerve, and then\ninvective with unsubtle charges of STUPID was loaded into the\ncatapult and flung across the sea ...\n\nI loathe politics getting in the way of something clean, robust, and\nuseful. I would be the last to advocate it: besides were I really\nconvinced that git MUST have this or die, I would try to write it\nmyself --- I was just hoping for an argument showing why it was such a\nlame-brained idea from a logical, not implementation, standpoint.\n\nThanks again for your time.\n\n\nBill\n"},{"id":"36384","messageId":"Pine.LNX.4.63.0703060026340.13683@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7042","inReplyTo":"17900.42415.750335.329874@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-05T23:32:28Z","receivedAt":"2007-03-05T23:32:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Mar 2007, Bill Lear wrote:\n\n> On Monday, March 5, 2007 at 14:37:15 (-0800) Linus Torvalds writes:\n> >On Mon, 5 Mar 2007, Bill Lear wrote:\n> >> I edit sourcefile.c, compile it, then commit it with\n> >> N=timestamp(sourcefile.c) on master. N is <\n> >> timestamp(.master/sourcefile.o). I then switch to branchX. N is\n> >> stored by git for master:sourcefile.c. No stored timestamp are on\n> >> this branch, so the file gets the timestamp it gets on checkout\n> >> M=timestamp(sourcefile.c). I compile the file again, all is well. I\n> >> move back to master branch. Git stores M as branchX:sourcefile.c Git\n> >> checks out the file, and stamps it with N. I do a make. No\n> >> recompilation happens.\n> >\n> >WHICH IS WRONG! You need to recompile, since the compile you did on the \n> >other branch DOES NOT MATCH in \"sourcefile.c\" any more. \n> \n> Well, I'll let it drop after this, but I think you're wrong. I do NOT\n> need it to recompile when I do the third make above.\n\nBill, maybe you don't want to hear it, but for all those following this \nthread, here is why you are wrong:\n\n\"make\" does _not_ match the time stamps of xyz.c and xyz.o. After you \n\"make\", the only thing which is guaranteed is that if xyz.c is _newer_ \nthan xyz.o, the compiler is started.\n\nExample:\n\n00:05 you pull upstream into your master branch, which has a newer xzy.c\n00:07 you type make. xyz.o is built, because make sees that xyz.c is \n newer than xyz.o\n00:12 you checkout your side branch, xyz.c is updated.\n00:13 you type make, and again xzy.o is built, because xyz.c is newer than \n xyz.o\n00:25 you switch back to your master branch.\n\nNow, if your wish would be granted, and xyz.c has the same timestamp as \nbefore, then it _still_ is older than xyz.o. So make will not rebuild it.\n\nBUT xyz.o is actually compiled from the side branch's version of xyz.c!\n\nHth,\nDscho\n"},{"id":"36385","messageId":"17900.43487.947400.649777@lisa.zopyra.com","threadId":"7042","inReplyTo":"Pine.LNX.4.63.0703060026340.13683@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git checkout preserve timestamp?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-05T23:38:07Z","receivedAt":"2007-03-05T23:38:07Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Tuesday, March 6, 2007 at 00:32:28 (+0100) Johannes Schindelin writes:\n>...\n>Bill, maybe you don't want to hear it, but for all those following this \n>thread, here is why you are wrong:\n\nAn actual demonstration of my stupidity is much, much preferable\nto a mere assertion of it, so I read the following with relish.\n\n>\"make\" does _not_ match the time stamps of xyz.c and xyz.o. After you \n>\"make\", the only thing which is guaranteed is that if xyz.c is _newer_ \n>than xyz.o, the compiler is started.\n>\n>Example:\n>\n>00:05 you pull upstream into your master branch, which has a newer xzy.c\n>00:07 you type make. xyz.o is built, because make sees that xyz.c is \n> newer than xyz.o\n>00:12 you checkout your side branch, xyz.c is updated.\n>00:13 you type make, and again xzy.o is built, because xyz.c is newer than \n> xyz.o\n>00:25 you switch back to your master branch.\n>\n>Now, if your wish would be granted, and xyz.c has the same timestamp as \n>before, then it _still_ is older than xyz.o. So make will not rebuild it.\n>\n>BUT xyz.o is actually compiled from the side branch's version of xyz.c!\n\nNo, I think you missed my point. There are two xyz.o's:\n\nOne in .master/xyz.o, and one in .branchX/xyz.o. So, you're example\nbecomes:\n\n00:05 you pull upstream into your master branch, which has a newer xzy.c\n00:07 you type make. .master/xyz.o is built, because make sees that xyz.c is \n newer than .master/xyz.o\n00:12 you checkout your side branch, xyz.c is updated.\n00:13 you type make, and .branchX/xzy.o is built, because xyz.c is newer than \n .branchX/xyz.o\n00:25 you switch back to your master branch.\n00:26 you type make, and nothing happens, as it should not. You are\n happy, and thank the git community for all of their heroic efforts.\n\nNow, I'm really going to go: the family is hungry and I've got\ndinner to prepare, so if you want to flame me for opening my mouth\nfurther, feel free.\n\n\nBill\n"},{"id":"36386","messageId":"Pine.LNX.4.63.0703060042040.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7042","inReplyTo":"17900.43487.947400.649777@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-05T23:50:16Z","receivedAt":"2007-03-05T23:50:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Mar 2007, Bill Lear wrote:\n\n> No, I think you missed my point. There are two xyz.o's:\n> \n> One in .master/xyz.o, and one in .branchX/xyz.o.\n\nWhy not put the two xyz.c's into .master/ and .branchX/ as well (surely, \nthe source files are small compared to the object files)? And just to make \nsure, the Makefile, too (some Makefile targets depend on the timestamp of \nthis, too).\n\nAnd to make sure that if we're switching to a third branch, let's put the \nfiles there, even when the side branch does not change them, otherwise \nA->B->C->A might fail.\n\nAnd while at it, we could put the information about which branch this is \ninto the corresponding directories, too! Otherwise, we could rename the \ndirectory by mistake, and the system would stop working.\n\nAnd the corresponding refs. They could be there, too.\n\nHth,\nDscho\n\nP.S.: Google for the complicator's gloves.\n"},{"id":"36388","messageId":"46a038f90703051606m7ce73f88hd0f6356969b73535@mail.gmail.com","threadId":"7042","inReplyTo":"17900.43487.947400.649777@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-03-06T00:06:21Z","receivedAt":"2007-03-06T00:06:21Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 3/6/07, Bill Lear wrote:\n> No, I think you missed my point. There are two xyz.o's:\n>\n> One in .master/xyz.o, and one in .branchX/xyz.o. So, you're example\n> becomes:\n\nFor most users, there are no dedicated branch-specific build\ndirectories. In any situation where there _are_ such\nbranch/arch/config-option specific builddirs, someone has crafted a\nneat multi- build system.\n\nNow, if you have such a build system, it's trivial to have a separate\ncheckout for each branch. Trying to push this bit of complexity into\ngit means that git would have an option that lets most users shoot\nthemselves in the foot, big time.\n\nSo - your ideas are OK, but just do all the trickery and magic for the\nsuper-build-system _in_ the super-build-system. You don't need any GIT\nchanges, just take advantage of the really fast and lightweight \"local\nclone\".\n\nI guess that's the definition of \"WRONG\" above. It's wrong and\nerror-prone for most users, and for the handsome few that could take\nadvantage of it, there are better ways of doing it.\n\ncheers,\n\n\nmartin\n"},{"id":"36387","messageId":"87zm6rqlpn.fsf@graviton.dyn.troilus.org","threadId":"7042","inReplyTo":"Pine.LNX.4.63.0703060042040.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git checkout preserve timestamp?","fromName":"Michael Poole","fromEmail":"mdpoole@troilus.org","sentAt":"2007-03-06T00:06:44Z","receivedAt":"2007-03-06T00:06:44Z","isPatch":false,"sender":{"key":"mdpoole@troilus.org","avatar":null},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Mon, 5 Mar 2007, Bill Lear wrote:\n>\n>> No, I think you missed my point. There are two xyz.o's:\n>> \n>> One in .master/xyz.o, and one in .branchX/xyz.o.\n>\n> Why not put the two xyz.c's into .master/ and .branchX/ as well (surely, \n> the source files are small compared to the object files)? And just to make \n> sure, the Makefile, too (some Makefile targets depend on the timestamp of \n> this, too).\n>\n> And to make sure that if we're switching to a third branch, let's put the \n> files there, even when the side branch does not change them, otherwise \n> A->B->C->A might fail.\n>\n> And while at it, we could put the information about which branch this is \n> into the corresponding directories, too! Otherwise, we could rename the \n> directory by mistake, and the system would stop working.\n>\n> And the corresponding refs. They could be there, too.\n\nThis all sounds a lot like git-clone's \"alternate\" code.\n\nDoes a repository cloned with the -s or --references flag have some\nsetting to make fetch and push work with the same remote repositories\nas the local origin, or do the remotes have to be manually propagated\nbetween the two local copies? If I git-fetch in the local clone, does\nit write the new objects to the local origin?\n\nMy own work habits are very similar to Bill Lear's, but my projects'\nbuild times are small enough that it's less pain to rebuild half the\nproject than to propagate changes recorded under $GIT_DIR between\nlocal branches. I have not found a git workflow that makes me\nentirely happy, but I suspect I just don't know the magic words.\n\nMichael Poole\n"},{"id":"36389","messageId":"Pine.LNX.4.63.0703060119320.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7042","inReplyTo":"87zm6rqlpn.fsf@graviton.dyn.troilus.org","subject":"Re: Git checkout preserve timestamp?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-06T00:20:31Z","receivedAt":"2007-03-06T00:20:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Mar 2007, Michael Poole wrote:\n\n> I have not found a git workflow that makes me entirely happy, but I \n> suspect I just don't know the magic words.\n\nSo, what do you want to do?\n\nCiao,\nDscho\n"},{"id":"36390","messageId":"20070306002125.GB19634@thunk.org","threadId":"7042","inReplyTo":"17900.43487.947400.649777@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-03-06T00:21:25Z","receivedAt":"2007-03-06T00:21:25Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Mon, Mar 05, 2007 at 05:38:07PM -0600, Bill Lear wrote:\n> \n> No, I think you missed my point. There are two xyz.o's:\n> \n> One in .master/xyz.o, and one in .branchX/xyz.o. So, you're example\n> becomes:\n\nAre you assuming that the makefile will automatically figure out which\nbranch you are on, and then redirect the .o to the right\n<.branch-name> directory? That's the only thing that makes sense,\nsince if you are using VPATH and depending on the developer being\ncd'ed into .master when the current branch is master, and cd'ed into\n.branchX when the current branch is branchX, and the developer types\nmake at when they are in the .master directory but the current branch\nis branchX, the result will be a huge, confusing mess.\n\nBut of course, the Makefile is under source control itself, and if at\na previous point in time the Makefile didn't have the magic .git\ndirectives, then you could do the build and have the the wrong thing\nhappen.\n\nSo it seems to be a very fragile solution compared to using multiple\nworking directories, or using ccache. It could be a tad bit more\nefficient than using ccache or multiple directories, but the real\nquestion is whether it really is worth the effort, and potential\nsupport difficulties if some confused user turns on this feature with\nthe proper git magic in their makefiles, and then the git mailing list\ngets the support burden.\n\n\nThat being said, I have often wished that there was some way I could\nuse all of those autogenerated html and man pages to spead up the\n\"make doc\" process in git. Ccache doesn't work because it doesn't\nunderstand asciidoc or xmlto, and there are all of these conveniently\ngenerated output files in the origin/man and origin/html, but unless\nwe are building exactly the same git release as described in the log\nmessage in the origin/man or origin/html branch. \n\nWhat would be really cool would be some way of generating some kind of\ndatabase that mapped the SHA1 hash of the SHA1 hash of the\ndependencies of a particular output file to the SHA1 hash of the glob\nof the generated output file as found in origin/man and origin/html.\nThis would basically be a way of integrating ccache functionality into\ngit, but for the HTML and man page outputs, which delta compress\nnicely and therefore makes a lot of sense to include in a git\nrepository like Junio is doing already. I'm not sure how much sense\nthis would make for storing the .o globs in the git repository\n(although there are some SCM's, like Clearcase who do this), but in\ntheory it could be used for that as well. The case is much more\ncompelling with the generated documentation files, though.\n\n\t\t\t\t\t- Ted\n"},{"id":"36391","messageId":"17900.46257.982036.751903@lisa.zopyra.com","threadId":"7042","inReplyTo":"Pine.LNX.4.63.0703060042040.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git checkout preserve timestamp?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-06T00:24:17Z","receivedAt":"2007-03-06T00:24:17Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Tuesday, March 6, 2007 at 00:50:16 (+0100) Johannes Schindelin writes:\n>On Mon, 5 Mar 2007, Bill Lear wrote:\n>> No, I think you missed my point. There are two xyz.o's:\n>> \n>> One in .master/xyz.o, and one in .branchX/xyz.o.\n>\n>Why not put the two xyz.c's into .master/ and .branchX/ as well (surely, \n>the source files are small compared to the object files)? And just to make \n>sure ...\n\nSo, be resorting to snide sarcasm, I can see you concede my point,\nfinally. Thank you.\n\n\nBill\n"},{"id":"36392","messageId":"7vodn7w6rz.fsf@assigned-by-dhcp.cox.net","threadId":"7042","inReplyTo":"87zm6rqlpn.fsf@graviton.dyn.troilus.org","subject":"Re: Git checkout preserve timestamp?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-06T00:32:48Z","receivedAt":"2007-03-06T00:32:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Poole writes:\n\n> This all sounds a lot like git-clone's \"alternate\" code.\n> ...\n> My own work habits are very similar to Bill Lear's, but my projects'\n> build times are small enough that it's less pain to rebuild half the\n> project than to propagate changes recorded under $GIT_DIR between\n> local branches. I have not found a git workflow that makes me\n> entirely happy, but I suspect I just don't know the magic words.\n\nThese days I use a few working trees that are connected to my\nprimary repository (which also has a working tree). The primary\nrepository is in /src/git, and other ones look like this:\n\n: gitster git.wk0; ls -l .git/\ntotal 120\ndrwxrwsr-x 3 junio src 4096 Mar 5 16:22 ./\ndrwxrwsr-x 15 junio src 16384 Mar 5 16:23 ../\n-rw-rw-r-- 1 junio src 41 Mar 5 16:22 HEAD\nlrwxrwxrwx 1 junio src 27 Mar 3 22:53 config -> /src/git/.git/config\nlrwxrwxrwx 1 junio src 26 Mar 3 22:53 hooks -> /src/git/.git/hooks/\n-rw-rw-r-- 1 junio src 82455 Mar 5 16:22 index\nlrwxrwxrwx 1 junio src 25 Mar 3 22:53 info -> /src/git/.git/info/\ndrwxrwsr-x 3 junio src 4096 Mar 3 22:59 logs/\nlrwxrwxrwx 1 junio src 28 Mar 3 22:53 objects -> /src/git/.git/objects/\nlrwxrwxrwx 1 junio src 32 Mar 3 22:53 packed-refs -> /src/git/.git/packed-refs\nlrwxrwxrwx 1 junio src 25 Mar 3 22:53 refs -> /src/git/.git/refs/\nlrwxrwxrwx 1 junio src 28 Mar 3 22:53 remotes -> /src/git/.git/remotes/\nlrwxrwxrwx 1 junio src 29 Mar 3 22:53 rr-cache -> /src/git/.git/rr-cache/\n\nIt shares everything other than HEAD and the index (the reflog\nfor branches are also shared by a symlink .git/logs/refs\npointing at the one in the primary repository).\n\nThis risks confusion for an uninitiated if you update a ref that\nis checked out in another working tree, but modulo that caveat\nit works reasonably well.\n\nWe might want to add an option to 'git-clone' to create\nsomething like this, but I am somewhat worried about the newbie\nconfusion factor. Perhaps...\n\n$ git clone --i-know-what-i-am-doing-give-me-an-alternate-working-tree \\\n /src/git /src/git.wk0\n"},{"id":"36394","messageId":"87wt1vqk9z.fsf@graviton.dyn.troilus.org","threadId":"7042","inReplyTo":"Pine.LNX.4.63.0703060119320.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git checkout preserve timestamp?","fromName":"Michael Poole","fromEmail":"mdpoole@troilus.org","sentAt":"2007-03-06T00:37:44Z","receivedAt":"2007-03-06T00:37:44Z","isPatch":false,"sender":{"key":"mdpoole@troilus.org","avatar":null},"body":"Johannes Schindelin writes:\n\n> Hi,\n>\n> On Mon, 5 Mar 2007, Michael Poole wrote:\n>\n>> I have not found a git workflow that makes me entirely happy, but I \n>> suspect I just don't know the magic words.\n>\n> So, what do you want to do?\n\nI want to have several local directories -- including build products\nand configuration files that are neither build products nor revision\ncontrolled -- that correspond to certain branches of one project.\n(Sometimes I have several trees for a single branch, to handle\ncompile-time alternatives.) I do not much care whether there is a\nseparate source tree for each of these or not.\n\nWhen I switch from working on one branch to another, I do not want\nfile timestamps to be any later than the corresponding object was\nchanged in the repository.\n\nWhen I change configuration options (including which branch(es) go to\nwhich remote(s)), I want to make that change in one $GIT_DIR rather\nthan in one $GIT_DIR for each branch.\n\nAs a lower priority, I would like a fetch on any of the branches to\nhave results that are visible to all my local copies without more\nnetwork traffic.\n\nThe first two goals are neatly solved by having several local clones.\nThe third and fourth are where I get lost.\n\nMichael Poole\n"},{"id":"36399","messageId":"esifio$j4f$1@sea.gmane.org","threadId":"7042","inReplyTo":"87zm6rqlpn.fsf@graviton.dyn.troilus.org","subject":"Re: Git checkout preserve timestamp?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-03-06T01:21:50Z","receivedAt":"2007-03-06T01:21:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Michael Poole writes:\n> \n>> This all sounds a lot like git-clone's \"alternate\" code.\n>> ...\n>> My own work habits are very similar to Bill Lear's, but my projects'\n>> build times are small enough that it's less pain to rebuild half the\n>> project than to propagate changes recorded under $GIT_DIR between\n>> local branches. I have not found a git workflow that makes me\n>> entirely happy, but I suspect I just don't know the magic words.\n> \n> These days I use a few working trees that are connected to my\n> primary repository (which also has a working tree). The primary\n> repository is in /src/git, and other ones look like this:\n> \n> : gitster git.wk0; ls -l .git/\n> total 120\n> drwxrwsr-x 3 junio src 4096 Mar 5 16:22 ./\n> drwxrwsr-x 15 junio src 16384 Mar 5 16:23 ../\n> -rw-rw-r-- 1 junio src 41 Mar 5 16:22 HEAD\n> lrwxrwxrwx 1 junio src 27 Mar 3 22:53 config -> /src/git/.git/config\n> lrwxrwxrwx 1 junio src 26 Mar 3 22:53 hooks -> /src/git/.git/hooks/\n> -rw-rw-r-- 1 junio src 82455 Mar 5 16:22 index\n> lrwxrwxrwx 1 junio src 25 Mar 3 22:53 info -> /src/git/.git/info/\n> drwxrwsr-x 3 junio src 4096 Mar 3 22:59 logs/\n> lrwxrwxrwx 1 junio src 28 Mar 3 22:53 objects -> /src/git/.git/objects/\n> lrwxrwxrwx 1 junio src 32 Mar 3 22:53 packed-refs -> /src/git/.git/packed-refs\n> lrwxrwxrwx 1 junio src 25 Mar 3 22:53 refs -> /src/git/.git/refs/\n> lrwxrwxrwx 1 junio src 28 Mar 3 22:53 remotes -> /src/git/.git/remotes/\n> lrwxrwxrwx 1 junio src 29 Mar 3 22:53 rr-cache -> /src/git/.git/rr-cache/\n\nBy the way, doing something like this, but not by using lots of symlinks,\nbut a kind of symref was idea behind Josef Weidendorfer .gitlink idea\n(search for '[RFC] Light-weight checkouts via \".gitlink\"')\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"36401","messageId":"Pine.LNX.4.63.0703060227150.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7042","inReplyTo":"17900.46257.982036.751903@lisa.zopyra.com","subject":"Re: Git checkout preserve timestamp?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-06T01:34:27Z","receivedAt":"2007-03-06T01:34:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Mar 2007, Bill Lear wrote:\n\n> On Tuesday, March 6, 2007 at 00:50:16 (+0100) Johannes Schindelin writes:\n> >On Mon, 5 Mar 2007, Bill Lear wrote:\n> >> No, I think you missed my point. There are two xyz.o's:\n> >> \n> >> One in .master/xyz.o, and one in .branchX/xyz.o.\n> >\n> >Why not put the two xyz.c's into .master/ and .branchX/ as well (surely, \n> >the source files are small compared to the object files)? And just to make \n> >sure ...\n> \n> So, be resorting to snide sarcasm, I can see you concede my point,\n> finally.\n\nIf you would have cared to actually read and try to understand my reply \nhere:\n\nhttp://article.gmane.org/gmane.comp.version-control.git/41136\n(This was 5 days and a very long thread ago)\n\nyou would have seen long ago that I actually see your problem, and want \nthe something similar myself. This is what I \"concede\". Always have. Only \nthat I use a sane method to achieve it. And that was my point you \nconsistently refused to accept.\n\nWhatever.\n\n> Thank you.\n\nYou don't have to thank me, as you clearly chose to ignore my help.\n\nCiao,\nDscho\n"},{"id":"36402","messageId":"Pine.LNX.4.63.0703060236390.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7042","inReplyTo":"87wt1vqk9z.fsf@graviton.dyn.troilus.org","subject":"Re: Git checkout preserve timestamp?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-06T01:40:13Z","receivedAt":"2007-03-06T01:40:13Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 5 Mar 2007, Michael Poole wrote:\n\n> When I change configuration options (including which branch(es) go to \n> which remote(s)), I want to make that change in one $GIT_DIR rather than \n> in one $GIT_DIR for each branch.\n\nThis can be solved by symlinking the config to one designated repo (let's \ncall it the \"master\" repo).\n\n> As a lower priority, I would like a fetch on any of the branches to have \n> results that are visible to all my local copies without more network \n> traffic.\n\nI'd just make a small script which I'd run from the \"master\" repo instead \nof saying \"git pull\":\n\n-- snip --\ngit pull || exit\nfor branch in branch1 branch2 branch3; do\n\tcd $branch && git pull .. $branch && cd .. || exit\ndone\n-- snap --\n\nThis assumes that you have named the side branches \"branch1\", \"branch2\" \nand \"branch3\", and that they are checked out in the subdirectories of the \nsame name.\n\nHth,\nDscho\n"},{"id":"36405","messageId":"17900.51972.524213.320552@lisa.zopyra.com","threadId":"7042","inReplyTo":"Pine.LNX.4.63.0703060227150.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Git checkout preserve timestamp?","fromName":"Bill Lear","fromEmail":"rael@zopyra.com","sentAt":"2007-03-06T01:59:32Z","receivedAt":"2007-03-06T01:59:32Z","isPatch":false,"sender":{"key":"rael@zopyra.com","avatar":"https://gravatar.com/avatar/c4f2d2790ca3828d3b4e7dfebabf61d2fe94fd82fa49cdac2a5295dd2d46a874?d=mp&s=160"},"body":"On Tuesday, March 6, 2007 at 02:34:27 (+0100) Johannes Schindelin writes:\n>On Mon, 5 Mar 2007, Bill Lear wrote:\n>> On Tuesday, March 6, 2007 at 00:50:16 (+0100) Johannes Schindelin writes:\n>> >On Mon, 5 Mar 2007, Bill Lear wrote:\n>> >> No, I think you missed my point. There are two xyz.o's:\n>> >> \n>> >> One in .master/xyz.o, and one in .branchX/xyz.o.\n>> >\n>> >Why not put the two xyz.c's into .master/ and .branchX/ as well (surely, \n>> >the source files are small compared to the object files)? And just to make \n>> >sure ...\n>> \n>> So, be resorting to snide sarcasm, I can see you concede my point,\n>> finally.\n>\n>If you would have cared to actually read and try to understand my reply \n>here:\n\nWhich I did, your baseless presumption to the contrary\nnotwithstanding.\n\n>you would have seen long ago that I actually see your problem, and want \n>the something similar myself. This is what I \"concede\". Always have. Only \n>that I use a sane method to achieve it. And that was my point you \n>consistently refused to accept.\n>...\n>You don't have to thank me, as you clearly chose to ignore my help.\n\nYour presumption is again false: your point was that my logic was\nconfused, that the entire dependency scheme I sketched out was\n\"stupid\", and you and another expended considerable effort to show how\nstupid this was, which now is clearly wrong --- my explanation and\nexample wasn't stupid after all. I was merely trying to convey WHAT I\nwanted to have happen, and HOW, logically speaking, it could. What I\ngot from you and one other ON THIS PART was that my logic was STUPID,\nIDIOTIC, etc., though to their credit, several others merely chimed in\nwith their opinion and helped the discussion along by presenting\nargument, example, and not invective and mere assertion that my\nlogic was very much beneath contempt.\n\nI saw and appreciated your earlier explanation, and will be trying to\nwork with it, and those the others suggested. My guess is that it\nwill not be as buttery-smooth as I would have hoped, but it will\nprobably do well enough.\n\nYour petulance and quick temper to dismiss someone as stupid merely\nbecause he pursues a line of discussion that you yourself admittedly\nconfuse, not to mention your name-calling --- both explicit and veiled\n--- really is not helpful, though your suggestions on how to use git\nbetter certainly are, and I do very much appreciate them here, and\nelsewhere.\n\n\nBill\n"},{"id":"36468","messageId":"loom.20070306T190954-291@post.gmane.org","threadId":"7042","inReplyTo":"7vodn7w6rz.fsf@assigned-by-dhcp.cox.net","subject":"Re: Git checkout preserve timestamp?","fromName":"Sergio Callegari","fromEmail":"scallegari@arces.unibo.it","sentAt":"2007-03-06T18:39:17Z","receivedAt":"2007-03-06T18:39:17Z","isPatch":false,"sender":{"key":"scallegari@arces.unibo.it","avatar":null},"body":"Junio C Hamano cox.net> writes:\n\n> \n> Michael Poole troilus.org> writes:\n> \n> > This all sounds a lot like git-clone's \"alternate\" code.\n> > ...\n> > My own work habits are very similar to Bill Lear's, but my projects'\n> > build times are small enough that it's less pain to rebuild half the\n> > project than to propagate changes recorded under $GIT_DIR between\n> > local branches. I have not found a git workflow that makes me\n> > entirely happy, but I suspect I just don't know the magic words.\n> \n> These days I use a few working trees that are connected to my\n> primary repository (which also has a working tree). The primary\n> repository is in /src/git, and other ones look like this:\n> \n> : gitster git.wk0; ls -l .git/\n> total 120\n> drwxrwsr-x 3 junio src 4096 Mar 5 16:22 ./\n> drwxrwsr-x 15 junio src 16384 Mar 5 16:23 ../\n> -rw-rw-r-- 1 junio src 41 Mar 5 16:22 HEAD\n> lrwxrwxrwx 1 junio src 27 Mar 3 22:53 config -> /src/git/.git/config\n> lrwxrwxrwx 1 junio src 26 Mar 3 22:53 hooks -> /src/git/.git/hooks/\n> -rw-rw-r-- 1 junio src 82455 Mar 5 16:22 index\n> lrwxrwxrwx 1 junio src 25 Mar 3 22:53 info -> /src/git/.git/info/\n> drwxrwsr-x 3 junio src 4096 Mar 3 22:59 logs/\n> lrwxrwxrwx 1 junio src 28 Mar 3 22:53 objects -> /src/git/.git/objects/\n> lrwxrwxrwx 1 junio src 32 Mar 3 22:53 packed-refs ->\n/src/git/.git/packed-refs\n> lrwxrwxrwx 1 junio src 25 Mar 3 22:53 refs -> /src/git/.git/refs/\n> lrwxrwxrwx 1 junio src 28 Mar 3 22:53 remotes -> /src/git/.git/remotes/\n> lrwxrwxrwx 1 junio src 29 Mar 3 22:53 rr-cache -> /src/git/.git/rr-cache/\n> \n> It shares everything other than HEAD and the index (the reflog\n> for branches are also shared by a symlink .git/logs/refs\n> pointing at the one in the primary repository).\n> \n> This risks confusion for an uninitiated if you update a ref that\n> is checked out in another working tree, but modulo that caveat\n> it works reasonably well.\n> \n> We might want to add an option to 'git-clone' to create\n> something like this, but I am somewhat worried about the newbie\n> confusion factor. Perhaps...\n> \n> $ git clone --i-know-what-i-am-doing-give-me-an-alternate-working-tree \\\n> /src/git /src/git.wk0\n> \n> \n\n\nThis looks very much like the .gitlink approach that was previously proposed on\nthe list, I think...\n\nIn that proposal, rather than having many symlinks in the .git repo, you would\nhave a single .gitlink one... (plus, obviously a live index and HEAD). \nPossibly, the .gitlink approach could be better, since in case the *real* repo\nneeds for some reason to be moved, then you just need to update a single link\nrather than many of them (this might also be safer... just imagine a scenario\nwhere one updates the links by hand and forgets to update one of them... and\nmore friendly to OSes disliking symbolic links).\n\nYou mention the fact that the only possible confusion here is if a ref that is\nchecked out in another working tree gets updated... Something like I update\nmaster on WT A, but another WT B has master checked out, so the status of the WT\nin B gets old with regard to the new branch tip... I guess that in this case\ncommitting in WT B could be a disaster...\n\nHowever, if in HEAD we stored not just the branch-ref, but also its commit ID\nthis case could become very easy to spot... and we could start behaving as if we\nwere headless... (possibly safer)... or am I completely wrong?\n\nSergio\n"}]}