{"thread":{"id":"8985","subject":"mtimes of working files","startedAt":"2007-07-11T15:08:12Z","lastAt":"2007-07-15T01:46:47Z","messageCount":24,"participants":["Yakov Lerner","Johannes Schindelin","Jan Hudec","Eric Wong","Andy Parkins","Randal L. Schwartz","David Woodhouse","Theodore Tso","Linus Torvalds","J. Bruce Fields","Jakub Narebski","Julian Phillips","Robin Rosenberg","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"47039","messageId":"f36b08ee0707110808h56ecbc7at9c92727c01cca508@mail.gmail.com","threadId":"8985","inReplyTo":null,"subject":"mtimes of working files","fromName":"Yakov Lerner","fromEmail":"iler.ml@gmail.com","sentAt":"2007-07-11T15:08:12Z","receivedAt":"2007-07-11T15:08:12Z","isPatch":false,"sender":{"key":"iler.ml@gmail.com","avatar":null},"body":"How difficult is it to have script (or maybe existing git option)\nthat would make mtimes of all working files equal to time of last commit ?\n\nThanks\nYakov\n"},{"id":"47052","messageId":"Pine.LNX.4.64.0707111902040.4516@racer.site","threadId":"8985","inReplyTo":"f36b08ee0707110808h56ecbc7at9c92727c01cca508@mail.gmail.com","subject":"Re: mtimes of working files","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-11T18:05:44Z","receivedAt":"2007-07-11T18:05:44Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 11 Jul 2007, Yakov Lerner wrote:\n\n> How difficult is it to have script (or maybe existing git option) that \n> would make mtimes of all working files equal to time of last commit ?\n\nI wonder if there was a secret alien invasion three days ago, with an evil \nmental virus weapon? It seems that this question has been asked three \ntimes in the last three days, twice on IRC, and once here.\n\nSo now, I really, really, really, (repeat that 97 more times in your head, \nplease) want to know why?\n\nThere must be some super uber-cool application of that, that people \n_insist_ on having it. And I do not want to be left out. Please tell me \nhow I could use that feature to make my workflow better.\n\nPlease, please, please.\n\nCiao,\nDscho\n\nP.S.: I know how to do it, too. And no, it does not help to try insulting \nme (unsuccessfully), even in a private chat.\n"},{"id":"47056","messageId":"f36b08ee0707111136t198cf559vc85c561decf9707f@mail.gmail.com","threadId":"8985","inReplyTo":"Pine.LNX.4.64.0707111902040.4516@racer.site","subject":"Re: mtimes of working files","fromName":"Yakov Lerner","fromEmail":"iler.ml@gmail.com","sentAt":"2007-07-11T18:36:25Z","receivedAt":"2007-07-11T18:36:25Z","isPatch":false,"sender":{"key":"iler.ml@gmail.com","avatar":null},"body":"On 7/11/07, Johannes Schindelin wrote:\n> On Wed, 11 Jul 2007, Yakov Lerner wrote:\n>\n> > How difficult is it to have script (or maybe existing git option) that\n> > would make mtimes of all working files equal to time of last commit ?\n>\n> I wonder if there was a secret alien invasion three days ago, with an evil\n> mental virus weapon? It seems that this question has been asked three\n> times in the last three days, twice on IRC, and once here.\n>\n> So now, I really, really, really, (repeat that 97 more times in your head,\n> please) want to know why?\n>\n> There must be some super uber-cool application of that, that people\n> _insist_ on having it. And I do not want to be left out.\n\nI gave you my reason on IRC, you ignored it. And you continued with\n\"You must defend your reason. Until you defend your reason, I do not give\nyou the solution, although I know it\". That sounded rude. If you are *curious*,\ntry to speak not from position of \"punishing authority\", but as curious people\nwould normally speak.\n\n> P.S.: I know how to do it, too. And no, it does not help to try insulting\n> me (unsuccessfully), even in a private chat.\n\nIf modifying mtimes of working file breaks the git, you should have\nmentioned that.\n\nI think it does not break anything in git. If this is so you should\nhave said so\nand to give the solution (which you said you know). I am lost in guesses\nas to what makes you keep your monopolistic solution secret.\nHope I can figure it without you.\n\nIn the chat, you told me that you know the answer but won't tell me.\n\nI have to tell you that demanding from me that I tell you why other\npeople asked this, and to withhold the answer on the ground that\nI must mind-read them and tell you their mind ... I think this is stupid\nattitude on yous part.\n\nYakov\n"},{"id":"47058","messageId":"Pine.LNX.4.64.0707111940080.4516@racer.site","threadId":"8985","inReplyTo":"f36b08ee0707111136t198cf559vc85c561decf9707f@mail.gmail.com","subject":"Re: mtimes of working files","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-07-11T18:42:10Z","receivedAt":"2007-07-11T18:42:10Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi list,\n\n> > > How difficult is it to have script (or maybe existing git option) \n> > > that would make mtimes of all working files equal to time of last \n> > > commit ?\n\nNow I slowly get really curious. Does _anybody_ know a scenario where \nthis makes sense?\n\n(No, Eric, there are enough corner cases where your example of a clustered \nwebserver breaks down, so I am not fully convinced that this is a useful \ncase.)\n\nAnybody enlighten me?\n\nCiao,\nDscho\n"},{"id":"47068","messageId":"20070711202615.GE3069@efreet.light.src","threadId":"8985","inReplyTo":"Pine.LNX.4.64.0707111940080.4516@racer.site","subject":"Re: mtimes of working files","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-07-11T20:26:15Z","receivedAt":"2007-07-11T20:26:15Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Wed, Jul 11, 2007 at 19:42:10 +0100, Johannes Schindelin wrote:\n> Hi list,\n> \n> > > > How difficult is it to have script (or maybe existing git option) \n> > > > that would make mtimes of all working files equal to time of last \n> > > > commit ?\n> \n> Now I slowly get really curious. Does _anybody_ know a scenario where \n> this makes sense?\n> \n> (No, Eric, there are enough corner cases where your example of a clustered \n> webserver breaks down, so I am not fully convinced that this is a useful \n> case.)\n> \n> Anybody enlighten me?\n\nI don't see any case where it would be useful, though I know some version\ncontrol systems that provide that feature. I think it is supposed to just be\nused for checking which view has newer version.\n\nI first thought the idea had something to do with make, but it will actually\npromptly break most build tools, because change to earlier version is\na change too, but they wouldn't detect it.\n\nHowever I am getting really curious about different thing -- the solution.\nBecause I think the arguments from keyword expansion discussion apply here\nthat prevent any *reliable* (you can have unreliable ones just as you can\nhave unreliable keyword expansion) solution.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"47120","messageId":"20070712062605.GD29676@muzzle","threadId":"8985","inReplyTo":"Pine.LNX.4.64.0707111940080.4516@racer.site","subject":"Re: mtimes of working files","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-07-12T06:26:05Z","receivedAt":"2007-07-12T06:26:05Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Johannes Schindelin wrote:\n> Hi list,\n> \n> > > > How difficult is it to have script (or maybe existing git option) \n> > > > that would make mtimes of all working files equal to time of last \n> > > > commit ?\n> \n> Now I slowly get really curious. Does _anybody_ know a scenario where \n> this makes sense?\n> \n> (No, Eric, there are enough corner cases where your example of a clustered \n> webserver breaks down, so I am not fully convinced that this is a useful \n> case.)\n\nI'll have to admit that most of my git usage is via git-svn, so I\nmostly deal with linear history and some branching, but no real merges\nin a git sense.\n\nThis is what I whipped up the other night:\n\nhttp://yhbt.net/git-set-file-times\n\n-----------------------------------8<-----------------------------------------\n#!/usr/bin/perl -w\nuse strict;\n\n# sets mtime and atime of files to the latest commit time in git\n#\n# This is useful for serving static content (managed by git)\n# from a cluster of identically configured HTTP servers. HTTP\n# clients and content delivery networks can get consistent\n# Last-Modified headers no matter which HTTP server in the\n# cluster they hit. This should improve caching behavior.\n#\n# This does not take into account merges, but if you're updating\n# every machine in the cluster from the same commit (A) to the\n# same commit (B), the mtimes will be _consistent_ across all\n# machines if not necesarily accurate.\n#\n# THIS IS NOT INTENDED TO OPTIMIZE BUILD SYSTEMS SUCH AS 'make'\n# YOU HAVE BEEN WARNED!\n\nmy %ls = ();\nmy $commit_time;\n\n$/ = \"\\0\";\nopen FH, 'git ls-files -z|' or die $!;\nwhile () {\n\tchomp;\n\t$ls{$_} = $_;\n}\nclose FH;\n\n\n$/ = \"\\n\";\nopen FH, \"git log -r --name-only --no-color --pretty=raw -z @ARGV |\" or die $!;\nwhile () {\n\tchomp;\n\tif (/^committer .*? (\\d+) (?:[\\-\\+]\\d+)$/) {\n\t\t$commit_time = $1;\n\t} elsif (s/\\0\\0commit [a-f0-9]{40}$//) {\n\t\tmy @files = delete @ls{split(/\\0/, $_)};\n\t\t@files = grep { defined $_ } @files;\n\t\tnext unless @files;\n\t\tutime $commit_time, $commit_time, @files;\n\t}\n\tlast unless %ls;\n\n}\nclose FH;\n-----------------------------------8<-----------------------------------------\n\n-- \nEric Wong\n"},{"id":"47127","messageId":"200707120857.53090.andyparkins@gmail.com","threadId":"8985","inReplyTo":"20070711202615.GE3069@efreet.light.src","subject":"Re: mtimes of working files","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-07-12T07:57:51Z","receivedAt":"2007-07-12T07:57:51Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 July 11, Jan Hudec wrote:\n\n> I first thought the idea had something to do with make, but it will\n> actually promptly break most build tools, because change to earlier version\n> is a change too, but they wouldn't detect it.\n\nI've found git's mtime setting to be the best where make is concerned so I \nwould hate to see it changed. Even when switching branches or rebasing or \nwhatever, only the changed files get rebuilt. The only time you get an \nunnecessary rebuild is if you do\n\n git checkout branch1\n git checkout branch2\n git checkout branch1\n\nBut we can hardly expect git to be responsible for that.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"47153","messageId":"86myy122mm.fsf@blue.stonehenge.com","threadId":"8985","inReplyTo":"20070712062605.GD29676@muzzle","subject":"Re: mtimes of working files","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2007-07-12T13:05:53Z","receivedAt":"2007-07-12T13:05:53Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Eric\" == Eric Wong writes:\n\nEric> open FH, \"git log -r --name-only --no-color --pretty=raw -z @ARGV |\" or die $!;\n\nThis breaks needlessly on @ARGV names that contain spaces. You want:\n\n open FH, \"-|\", qw(git log -r --name-only --no-color --pretty=raw -z), @ARGV or die $!;\n\nBut that sounds familiar.... I think there's a function somewhere included in\nthe git distro that does this. I'm old and senile though. :)\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"47179","messageId":"1184261246.31598.139.camel@pmac.infradead.org","threadId":"8985","inReplyTo":"200707120857.53090.andyparkins@gmail.com","subject":"Re: mtimes of working files","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2007-07-12T17:27:26Z","receivedAt":"2007-07-12T17:27:26Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2007-07-12 at 08:57 +0100, Andy Parkins wrote:\n> The only time you get an unnecessary rebuild is if you do\n> \n> git checkout branch1\n> git checkout branch2\n> git checkout branch1\n> \n> But we can hardly expect git to be responsible for that. \n\nIndeed. That's a user error. Git makes it cheap and easy to have\nseparate _trees_. Just use them -- branches are just another mental\nhangover from CVS which we should try to cure ourselves of :)\n\n-- \ndwmw2\n"},{"id":"47183","messageId":"20070712182502.GA24854@hand.yhbt.net","threadId":"8985","inReplyTo":"86myy122mm.fsf@blue.stonehenge.com","subject":"Re: mtimes of working files","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-07-12T18:25:02Z","receivedAt":"2007-07-12T18:25:02Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"\"Randal L. Schwartz\" wrote:\n> >>>>> \"Eric\" == Eric Wong writes:\n> \n> Eric> open FH, \"git log -r --name-only --no-color --pretty=raw -z @ARGV |\" or die $!;\n> \n> This breaks needlessly on @ARGV names that contain spaces. You want:\n> \n> open FH, \"-|\", qw(git log -r --name-only --no-color --pretty=raw -z), @ARGV or die $!;\n> \n> But that sounds familiar.... I think there's a function somewhere included in\n> the git distro that does this. I'm old and senile though. :)\n\nYep, I added that @ARGV at the last second and didn't care enough to fix\nit. I didn't want to link this into the git build system so that it\ncould find Git.pm, either.\n\nSo I'll just go with this 5.8-ism. I didn't really intend for that\nscript to go anywhere, maybe somebody who wants it badly enough can make\nthe ls-files call respect any path limiting intended in @ARGV but still\nallow revision ranges to be passed (my original intention of supporting\n@ARGV was only revision ranges).\n\n-- \nEric Wong\n"},{"id":"47229","messageId":"20070713003700.GA21304@thunk.org","threadId":"8985","inReplyTo":"1184261246.31598.139.camel@pmac.infradead.org","subject":"Re: mtimes of working files","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-07-13T00:37:01Z","receivedAt":"2007-07-13T00:37:01Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Thu, Jul 12, 2007 at 06:27:26PM +0100, David Woodhouse wrote:\n> On Thu, 2007-07-12 at 08:57 +0100, Andy Parkins wrote:\n> > The only time you get an unnecessary rebuild is if you do\n> > \n> > git checkout branch1\n> > git checkout branch2\n> > git checkout branch1\n> > \n> > But we can hardly expect git to be responsible for that. \n> \n> Indeed. That's a user error. Git makes it cheap and easy to have\n> separate _trees_. Just use them -- branches are just another mental\n> hangover from CVS which we should try to cure ourselves of :)\n\nPersonally, I just use branches a huge amount, and I will often do\n\ngit checkout branch1\n\ngit commit --amend\n\ngit checkout branch2\n\ngit commit\n\ngit checkout branch1\n\n\nRebuilding isn't a problem, because I use ccache. :-)\n\nI could use separate trees, I suppose, but then I have to keep\nmultiple copies of the .o files around in all of those separate trees,\nand it's cheaper and more efficient to keep them in the ccache cache\nIMHO. And with 7200 RPM laptop drives and dual core processors\ncombined with ccache, I hardly notice the rebuild/relink time.\n\n\t \t \t \t - Ted\n"},{"id":"47291","messageId":"1184367619.2785.58.camel@shinybook.infradead.org","threadId":"8985","inReplyTo":"20070713003700.GA21304@thunk.org","subject":"Re: mtimes of working files","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2007-07-13T23:00:19Z","receivedAt":"2007-07-13T23:00:19Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Thu, 2007-07-12 at 20:37 -0400, Theodore Tso wrote:\n> I could use separate trees, I suppose, but then I have to keep\n> multiple copies of the .o files around in all of those separate trees,\n> and it's cheaper and more efficient to keep them in the ccache cache\n> IMHO. And with 7200 RPM laptop drives and dual core processors\n> combined with ccache, I hardly notice the rebuild/relink time. \n\nI'm not entirely sure why it would be cheaper and more efficient to keep\nyour object files in ccache rather than in the build tree. It takes time\nfor ccache to do the preprocessing and fetch them, and it takes even\nmore time to redo the linking.\n\nDisk space is cheap too, and you can always 'make clean' or even remove\nall the source files too, if you really care.\n\nNot that I'm presuming to suggest that there's anything _wrong_ with\nyour choice of workflow, of course -- it just doesn't really make much\nsense to me.\n\nBranches just seem like a source of complexity and hence pain. Using git\nwas just starting to become sensible for newbies, and now when people\nare forced to deal with multiple branches it's all horribly painful\nagain.\n\n-- \ndwmw2\n"},{"id":"47294","messageId":"alpine.LFD.0.999.0707131617270.20061@woody.linux-foundation.org","threadId":"8985","inReplyTo":"1184367619.2785.58.camel@shinybook.infradead.org","subject":"Re: mtimes of working files","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-13T23:18:03Z","receivedAt":"2007-07-13T23:18:03Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 14 Jul 2007, David Woodhouse wrote:\n> \n> Branches just seem like a source of complexity and hence pain. Using git\n> was just starting to become sensible for newbies, and now when people\n> are forced to deal with multiple branches it's all horribly painful\n> again.\n\nWhy would anybody force you to do that?\n\nThe \"switch between branchs in the same repo\" is really convenient. But \nnobody *forces* you to do it.\n\n\t\t\tLinus\n"},{"id":"47295","messageId":"1184370414.2785.79.camel@shinybook.infradead.org","threadId":"8985","inReplyTo":"alpine.LFD.0.999.0707131617270.20061@woody.linux-foundation.org","subject":"Re: mtimes of working files","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2007-07-13T23:46:54Z","receivedAt":"2007-07-13T23:46:54Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Fri, 2007-07-13 at 16:18 -0700, Linus Torvalds wrote:\n> Why would anybody force you to do that?\n> \n> The \"switch between branchs in the same repo\" is really convenient.\n> But nobody *forces* you to do it. \n\nThis is true. I already mirror a bunch of CVS and SVN repositories into\ngit so that I can use them without too much pain¹, and I can do the same\nfor git trees which use branches too; mirroring them into a bunch of\nseparate trees for easy access.\n\nOn the occasions I actually try to _use_ branches, I find it very\nsuboptimal. Perhaps it's just because I'm stupid. I'm sure that's why I\nended up committing changes to the wrong branch. But having to rebuild\n(even with ccache) after changing branches is a PITA. Just changing\nbranches at all is a PITA if you have uncommitted changes (which I\nusually do because I've usually tested _some_ random patch in a build\ntree for the hardware which is closest to hand). Pulling a whole bunch\nof unwanted changes on the 'development' branch while on GPRS, when all\nI really needed was a single commit from the 'stable' branch also didn't\namuse me, although I'm sure if I had the time to play with it I'd have\nbeen able to avoid that.\n\nI can, and do, mirror stuff from all kinds of suboptimal version control\nsystems into single-branch git trees. And I include multi-branched git\ntrees in my definition of 'suboptimal'. My ability to do that doesn't\nreally help the newbies who are expected with branches, though.\n\nI just wish people would make stuff available on the _servers_ in\nseparate trees rather than in branches -- if some people prefer branches\nlocally then that's their option; at the moment we kind of force people\ninto it. They _could_ avoid it but they'd have to know what they're\ndoing.\n\nBut I didn't really mean to start an argument; it's just my opinion.\n\n-- \ndwmw2\n\n¹ and I'd do the same for Hg if I could get hg2git to work.\n"},{"id":"47297","messageId":"alpine.LFD.0.999.0707131704000.20061@woody.linux-foundation.org","threadId":"8985","inReplyTo":"1184370414.2785.79.camel@shinybook.infradead.org","subject":"Re: mtimes of working files","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-07-14T00:10:16Z","receivedAt":"2007-07-14T00:10:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 14 Jul 2007, David Woodhouse wrote:\n> \n> On the occasions I actually try to _use_ branches, I find it very\n> suboptimal.\n\nThis seems to be very personal.\n\nI tend to use just temporary branches, but I love just going on another \nbranch, fixing something up, and working on that without having to set up \na whole new tree. It's *much* faster to just switch branches than to do \neven a local clone, because I usually would work on something that is \npretty close to the HEAD anyway, so the cost of rewriting a few hundred \nfiles is much less than checking out the 22,000 files all over again.\n\nBut I literally tend to just use branches for something small. I don't \npersonally tend to have any long-term live branches (apart from the remove \nones, obviously). I create a branch, do something in it, merge it, and \ngo back to master.\n\nThe last example of this for me was just re-doing a pull by Ingo, because \nhe had created some really strange commit in his tree, so I fetched his \nstuff, re-created his branch locally without the thing, and then merged \nit. And then I just deleted the branch.\n\n> But having to rebuild (even with ccache) after changing branches is a \n> PITA.\n\nI don't even use ccache, and I don't care. Probably because most of the \ntime the rebuild time really isn't that long for me, and for the kernel, \nthe much more painful part is actually the rebooting part.\n\nBut the place where branches *really* rock is when you don't even switch \nto them, but use the data from them locally (cherry-picking from them, \nor doing something like \"git show origin/pu:builtin-blame.c\" etc).\n\nAnd for that to work, you have to get used to having multiple branches in \nthe tree, even if you don't check them out - and once you do that, \nswitching between them isn't really that confusing any more, because it's \nalready part of your \"mind map\" of how the repo works.\n\n\t\t\tLinus\n"},{"id":"47299","messageId":"1184373393.2785.99.camel@shinybook.infradead.org","threadId":"8985","inReplyTo":"alpine.LFD.0.999.0707131704000.20061@woody.linux-foundation.org","subject":"Re: mtimes of working files","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2007-07-14T00:36:33Z","receivedAt":"2007-07-14T00:36:33Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Fri, 2007-07-13 at 17:10 -0700, Linus Torvalds wrote:\n> \n> On Sat, 14 Jul 2007, David Woodhouse wrote:\n> > \n> > On the occasions I actually try to _use_ branches, I find it very\n> > suboptimal.\n> \n> This seems to be very personal.\n\nYeah, much of it. Although I've also seen other people trying to get to\ngrips with git and tripping up over branches recently. It _was_ getting\neasier, for a while :)\n\n> But I literally tend to just use branches for something small. I don't \n> personally tend to have any long-term live branches (apart from the remove \n> ones, obviously). I create a branch, do something in it, merge it, and \n> go back to master.\n\nI don't usually bother with that. I just do something in HEAD and then\nreset (possibly after pushing it to some tree elsewhere for posterity).\n\n> I don't even use ccache, and I don't care. Probably because most of the \n> time the rebuild time really isn't that long for me, and for the kernel, \n> the much more painful part is actually the rebooting part.\n\nI can usually find some other machine to reboot than the machine I'm\nworking on. Don't these people send you enough toys? :)\n\nI've also spent most of the last year travelling and hence working on my\nlaptop, which isn't the beefiest build machine I've ever had the\npleasure of using. Changing branches, when I've done it, really has been\na pain.\n\n> But the place where branches *really* rock is when you don't even switch \n> to them, but use the data from them locally (cherry-picking from them, \n> or doing something like \"git show origin/pu:builtin-blame.c\" etc).\n\nYou can achieve much of that just by sharing object directories, and\nI'll admit that sometimes I do set up temporary branches just for the\npurpose of cherry-picking by name ('foo^^' etc.) without having to paste\nsha1sums from the other tree.\n\n> And for that to work, you have to get used to having multiple branches in \n> the tree, even if you don't check them out - and once you do that, \n> switching between them isn't really that confusing any more, because it's \n> already part of your \"mind map\" of how the repo works.\n\nI'm sure it's true that if I persist I'll get used to it, as will the\nnewbies who have trouble with branches. But mostly I suspect that I'll\nget used to it by learning how best to work around it and keep separate\ntrees of my own, even when people persist in having multiple branches on\ntheir servers. And while today's set of newbies will get used to it,\ntomorrow's set of newbies will also find it troubling.\n\nNothing really prevents you from using branches _locally_ if you want\nto, but still keeping separate trees on the _servers_. I just think that\nmight be a more cunning way forward. But as you correctly point out,\nthat's just my personal viewpoint.\n\n-- \ndwmw2\n"},{"id":"47301","messageId":"20070714004433.GB10131@fieldses.org","threadId":"8985","inReplyTo":"1184373393.2785.99.camel@shinybook.infradead.org","subject":"Re: mtimes of working files","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-07-14T00:44:33Z","receivedAt":"2007-07-14T00:44:33Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sat, Jul 14, 2007 at 01:36:33AM +0100, David Woodhouse wrote:\n> Yeah, much of it. Although I've also seen other people trying to get to\n> grips with git and tripping up over branches recently.\n\nCould you give any details? What specifically was it they were having\ntrouble with?\n\n--b.\n"},{"id":"47302","messageId":"1184374174.2785.104.camel@shinybook.infradead.org","threadId":"8985","inReplyTo":"20070714004433.GB10131@fieldses.org","subject":"Re: mtimes of working files","fromName":"David Woodhouse","fromEmail":"dwmw2@infradead.org","sentAt":"2007-07-14T00:49:34Z","receivedAt":"2007-07-14T00:49:34Z","isPatch":false,"sender":{"key":"dwmw2@infradead.org","avatar":"https://gravatar.com/avatar/7afd4f07e0cf7d7e046ae2d23678296b37777c96488e6f3451e78a5514154ebd?d=mp&s=160"},"body":"On Fri, 2007-07-13 at 20:44 -0400, J. Bruce Fields wrote:\n> On Sat, Jul 14, 2007 at 01:36:33AM +0100, David Woodhouse wrote:\n> > Yeah, much of it. Although I've also seen other people trying to get\n> > to grips with git and tripping up over branches recently.\n> \n> Could you give any details? What specifically was it they were having\n> trouble with? \n\nJust conversations on IRC where stuff had to be explained. People not\nunderstanding that they'd actually cloned _multiple_ branches and they\nneeded to select the one they wanted, making the same kind of stupid\nmistakes I did with committing to the wrong place, etc. Nothing specific\nstands out as being fixable, certainly.\n\nBranches have their place, and some people seem very happy with them as\npart of their local workflow. I just wonder if we have to have them on\nthe servers too; that's all.\n\n-- \ndwmw2\n"},{"id":"47304","messageId":"f798sr$n1g$1@sea.gmane.org","threadId":"8985","inReplyTo":"1184374174.2785.104.camel@shinybook.infradead.org","subject":"Re: mtimes of working files","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-07-14T01:29:02Z","receivedAt":"2007-07-14T01:29:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"David Woodhouse wrote:\n\n> Branches have their place, and some people seem very happy with them as\n> part of their local workflow. I just wonder if we have to have them on\n> the servers too; that's all.\n \nMultiple branches in one [public] repository help sharing data. While you\ncan do similar with sharing object database (via alternates mechanism)\nthe second solution has drawbacks the multiple branches didn't have.\n\nIIRC multiple branches was not something _planned_ by Linus when creating\ngit; users requested this feature, and it turned out to be useful.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"47350","messageId":"Pine.LNX.4.64.0707141402230.3133@beast.quantumfyre.co.uk","threadId":"8985","inReplyTo":"1184370414.2785.79.camel@shinybook.infradead.org","subject":"Re: mtimes of working files","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-07-14T13:09:57Z","receivedAt":"2007-07-14T13:09:57Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sat, 14 Jul 2007, David Woodhouse wrote:\n\n> On Fri, 2007-07-13 at 16:18 -0700, Linus Torvalds wrote:\n>> Why would anybody force you to do that?\n>>\n>> The \"switch between branchs in the same repo\" is really convenient.\n>> But nobody *forces* you to do it.\n>\n> This is true. I already mirror a bunch of CVS and SVN repositories into\n> git so that I can use them without too much pain¹, and I can do the same\n> for git trees which use branches too; mirroring them into a bunch of\n> separate trees for easy access.\n>\n> On the occasions I actually try to _use_ branches, I find it very\n> suboptimal. Perhaps it's just because I'm stupid. I'm sure that's why I\n> ended up committing changes to the wrong branch. But having to rebuild\n> (even with ccache) after changing branches is a PITA. Just changing\n> branches at all is a PITA if you have uncommitted changes (which I\n> usually do because I've usually tested _some_ random patch in a build\n> tree for the hardware which is closest to hand). Pulling a whole bunch\n> of unwanted changes on the 'development' branch while on GPRS, when all\n> I really needed was a single commit from the 'stable' branch also didn't\n> amuse me, although I'm sure if I had the time to play with it I'd have\n> been able to avoid that.\n>\n> I can, and do, mirror stuff from all kinds of suboptimal version control\n> systems into single-branch git trees. And I include multi-branched git\n> trees in my definition of 'suboptimal'. My ability to do that doesn't\n> really help the newbies who are expected with branches, though.\n\nYou can flatten a multi-branched git repo without mirroring into multiple \nsingle-branch repos - The ability to pull out branches into separate trees \nfrom a single repository was what the git-new-workdir script in contrib \nwas written for.\n\nWhile I find branches quite a natural concept having used the for the past \nfew years in Subversion and CVS before that (and after that branches in \ngit are a delight to use), I still like to have access to all of the \nbranches that I am working on as separate trees.\n\ngit-new-workdir allowed me to do that by scripting an approach described \nby Junio. Though maybe it has been superseeded by some built-in feature? \nI haven't been following things that closely recently, and ISTR that there \nwas talk of a feature that would make the script obsolete.\n\n-- \nJulian\n\n ---\nYou're at Witt's End."},{"id":"47352","messageId":"200707141523.32929.robin.rosenberg.lists@dewire.com","threadId":"8985","inReplyTo":"1184374174.2785.104.camel@shinybook.infradead.org","subject":"Re: mtimes of working files","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-07-14T13:23:32Z","receivedAt":"2007-07-14T13:23:32Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"lördag 14 juli 2007 skrev David Woodhouse:\n> On Fri, 2007-07-13 at 20:44 -0400, J. Bruce Fields wrote:\n> > On Sat, Jul 14, 2007 at 01:36:33AM +0100, David Woodhouse wrote:\n> > > Yeah, much of it. Although I've also seen other people trying to get\n> > > to grips with git and tripping up over branches recently.\n> > \n> > Could you give any details? What specifically was it they were having\n> > trouble with? \n> \n> Just conversations on IRC where stuff had to be explained. People not\n> understanding that they'd actually cloned _multiple_ branches and they\n> needed to select the one they wanted, making the same kind of stupid\n> mistakes I did with committing to the wrong place, etc. Nothing specific\n> stands out as being fixable, certainly.\n\nThat's why there are scripts that modify the bash prompt to show the current branch.\nI made one for stacked git (it works with plain git too). The git completion scripts have \nsomething also I think\n\nIt helps a lot for those of us with bad memory implants.\n\n> Branches have their place, and some people seem very happy with them as\n> part of their local workflow. I just wonder if we have to have them on\n> the servers too; that's all.\n\nBranches are bad if you don't need them as is any feature you don't need is bad, it is\njust that many people need branches. Branches are a pain to manage with many SCM\ntools, except git, which solves most of the problems with branches.\n\n-- robin\n"},{"id":"47385","messageId":"20070714222221.GB3678@efreet.light.src","threadId":"8985","inReplyTo":"1184370414.2785.79.camel@shinybook.infradead.org","subject":"Re: mtimes of working files","fromName":"Jan Hudec","fromEmail":"bulb@ucw.cz","sentAt":"2007-07-14T22:22:21Z","receivedAt":"2007-07-14T22:22:21Z","isPatch":false,"sender":{"key":"bulb@ucw.cz","avatar":null},"body":"On Sat, Jul 14, 2007 at 00:46:54 +0100, David Woodhouse wrote:\n> On the occasions I actually try to _use_ branches, I find it very\n> suboptimal. Perhaps it's just because I'm stupid. I'm sure that's why I\n> ended up committing changes to the wrong branch. But having to rebuild\n> (even with ccache) after changing branches is a PITA. Just changing\n> branches at all is a PITA if you have uncommitted changes (which I\n> usually do because I've usually tested _some_ random patch in a build\n> tree for the hardware which is closest to hand). Pulling a whole bunch\n> of unwanted changes on the 'development' branch while on GPRS, when all\n> I really needed was a single commit from the 'stable' branch also didn't\n> amuse me, although I'm sure if I had the time to play with it I'd have\n> been able to avoid that.\n\nI have to say it's the exact oposite for me. I used to have branches checked\nout separately, with arch and than bzr, and I find the git way much easier in\nthe end. Exactly because I don't need the multiple checkouts. Often, each of\nthem needed to contain some local stuff (like test data or some configuration\nfor building) and rebuilding in one of them does not help the others (usually\nthey are very close to each other).\n\nFor uncommited changes, git makes it possible (yes, I agree it is an extra\ncommand one might want to avoid) to commit them and them uncommit or amend\nthe commit when you get back to them.\n\nPulling something into the wrong place can happen quite as likely, at least\nto me, with separate checkouts as with switching in one place. And than git\nactually makes it much easier to fix it when you are in a single tree. Until\nyou publish, you git allows fixing anything with commit --amend and/or reset.\n\n> I can, and do, mirror stuff from all kinds of suboptimal version control\n> systems into single-branch git trees. And I include multi-branched git\n> trees in my definition of 'suboptimal'. My ability to do that doesn't\n> really help the newbies who are expected with branches, though.\n\nFor newbies, the bzr approach is much easier to grasp, even though I really\nfind that the git one is actually a little nicer to work with.\n\n> I just wish people would make stuff available on the _servers_ in\n> separate trees rather than in branches -- if some people prefer branches\n> locally then that's their option; at the moment we kind of force people\n> into it. They _could_ avoid it but they'd have to know what they're\n> doing.\n\nYou can treat the servers as separate trees! When cloning and/or pulling, you\ncan set up to pull just the one branch you are interested in. Having them as\nseparate trees would either be inefficient (the data would not be shared), or\nwould bring it's own class of problems.\n\nI would like, if git could have something like \"checkouts\". The idea is, that\na checkout would contain the working tree, .git/HEAD saying what revision it\nis at and .git/index and everything else would be linked from the repository\nit is checked out from. That would allow you to have different branches\nchecked out at different places, while not only sharing all the data, but\nalso all of them available in all the checkouts and commands like pull\nupdating it in all of them.\n\nIt would be IMHO possible to symlink all the stuff in .git except HEAD and\nindex, except for one problem. This is if you have two checkouts from the\nsame branch and check out of them, the other one needs to know, that it's\nhead should now be detached to stay where it was.\n\n-- \n\t\t\t\t\t\t Jan 'Bulb' Hudec \n"},{"id":"47386","messageId":"Pine.LNX.4.64.0707142331380.14090@beast.quantumfyre.co.uk","threadId":"8985","inReplyTo":"20070714222221.GB3678@efreet.light.src","subject":"Re: mtimes of working files","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-07-14T22:36:00Z","receivedAt":"2007-07-14T22:36:00Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sun, 15 Jul 2007, Jan Hudec wrote:\n\n> I would like, if git could have something like \"checkouts\". The idea is, that\n> a checkout would contain the working tree, .git/HEAD saying what revision it\n> is at and .git/index and everything else would be linked from the repository\n> it is checked out from. That would allow you to have different branches\n> checked out at different places, while not only sharing all the data, but\n> also all of them available in all the checkouts and commands like pull\n> updating it in all of them.\n>\n> It would be IMHO possible to symlink all the stuff in .git except HEAD and\n> index, except for one problem. This is if you have two checkouts from the\n> same branch and check out of them, the other one needs to know, that it's\n> head should now be detached to stay where it was.\n\nYou basically just described what the git-new-workdir script in \ncontrib/workdir does ... it doesn't address the issue of reference \nupdating.\n\n-- \nJulian\n\n ---\nMost people's favorite way to end a game is by winning.\n"},{"id":"47393","messageId":"Pine.LNX.4.64.0707142135090.14596@iabervon.org","threadId":"8985","inReplyTo":"Pine.LNX.4.64.0707142331380.14090@beast.quantumfyre.co.uk","subject":"Re: mtimes of working files","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-07-15T01:46:47Z","receivedAt":"2007-07-15T01:46:47Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 14 Jul 2007, Julian Phillips wrote:\n\n> On Sun, 15 Jul 2007, Jan Hudec wrote:\n> \n> > It would be IMHO possible to symlink all the stuff in .git except HEAD and\n> > index, except for one problem. This is if you have two checkouts from the\n> > same branch and check out of them, the other one needs to know, that it's\n> > head should now be detached to stay where it was.\n> \n> You basically just described what the git-new-workdir script in\n> contrib/workdir does ... it doesn't address the issue of reference updating.\n\nThat's where keeping the index's parents in the index would help. Various \npeople have implemented it at various times, but it's never quite become \nsufficiently important to people to have the correct behavior worked out \nand put into mainline. IIRC, not too long ago Junio had an implementation \nin pu, but ended up dropping it because almost nobody would see a difference, \nand the people who did see a difference only had it interfere with what \nthey were trying to do.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}