{"thread":{"id":"27511","subject":"speed of git reset -- file","startedAt":"2011-05-31T19:00:15Z","lastAt":"2011-06-02T04:46:38Z","messageCount":17,"participants":["Joey Hess","Jeff King","Junio C Hamano","Matthieu Moy","Nguyen Thai Ngoc Duy"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"169068","messageId":"20110531190015.GA12113@gnu.kitenet.net","threadId":"27511","inReplyTo":null,"subject":"speed of git reset -- file","fromName":"Joey Hess","fromEmail":"joey@kitenet.net","sentAt":"2011-05-31T19:00:15Z","receivedAt":"2011-05-31T19:00:15Z","isPatch":false,"sender":{"key":"joey@kitenet.net","avatar":"https://avatars.githubusercontent.com/u/16392?v=4"},"body":"I'd expect that resetting a single file would need to update the index,\nreading some objects from .git to do it.\n\nBut according to strace, it also stats every file in the working tree.\nI have lots of files, and so that is very slow. Is it really necessary?\n\ngit version 1.7.5.1\n\n-- \nsee shy jo\n"},{"id":"169076","messageId":"20110531212639.GA13234@sigill.intra.peff.net","threadId":"27511","inReplyTo":"20110531190015.GA12113@gnu.kitenet.net","subject":"Re: speed of git reset -- file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-31T21:26:39Z","receivedAt":"2011-05-31T21:26:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 31, 2011 at 03:00:15PM -0400, Joey Hess wrote:\n\n> I'd expect that resetting a single file would need to update the index,\n> reading some objects from .git to do it.\n> \n> But according to strace, it also stats every file in the working tree.\n> I have lots of files, and so that is very slow. Is it really necessary?\n\nConceptually, no, I don't think so. But remember that your \"file\" is not\nreally a file at all, but a pathspec that may match many entries. Also,\nwe try not to overwrite things that would not be changed. So that\ncomplicates it a little bit.\n\nYou can see the implementation in builtin/reset.c:read_from_tree. We\nactually diff the tree (e.g., HEAD) against the index, and update only\nthe differences. Unfortunately this seems to trash the index (see the\ncomment there), and we end up having to refresh it. I'm not sure how\navoidable that trashing is. I think we're getting deep into how\nunpack_trees works, and it handles a lot more cases than just \"unpack a\nfew entries\". So I don't know how easy it would be to separate this\nrelatively simple case from more complex ones.\n\n-Peff\n"},{"id":"169079","messageId":"7vpqmyilj6.fsf@alter.siamese.dyndns.org","threadId":"27511","inReplyTo":"20110531212639.GA13234@sigill.intra.peff.net","subject":"Re: speed of git reset -- file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-31T21:54:05Z","receivedAt":"2011-05-31T21:54:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Conceptually, no, I don't think so.\n\nHmm, don't we have to say like all other reset types which paths are\ndirty, i.e.\n\n $ git reset HEAD -- diff.c\n Unstaged changes after reset:\n M diff.c\n M diff.h\n\nwhich would mean we would need to refresh the index anyway?\n"},{"id":"169081","messageId":"20110531221332.GA15217@sigill.intra.peff.net","threadId":"27511","inReplyTo":"7vpqmyilj6.fsf@alter.siamese.dyndns.org","subject":"Re: speed of git reset -- file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-31T22:13:32Z","receivedAt":"2011-05-31T22:13:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 31, 2011 at 02:54:05PM -0700, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > Conceptually, no, I don't think so.\n> \n> Hmm, don't we have to say like all other reset types which paths are\n> dirty, i.e.\n> \n> $ git reset HEAD -- diff.c\n> Unstaged changes after reset:\n> M diff.c\n> M diff.h\n> \n> which would mean we would need to refresh the index anyway?\n\nTrue, though if you pass \"-q\", we could bypass that step.\n\n-Peff\n"},{"id":"169082","messageId":"vpqr57e1pt8.fsf@bauges.imag.fr","threadId":"27511","inReplyTo":"7vpqmyilj6.fsf@alter.siamese.dyndns.org","subject":"Re: speed of git reset -- file","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-05-31T22:13:39Z","receivedAt":"2011-05-31T22:13:39Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Jeff King writes:\n>\n>> Conceptually, no, I don't think so.\n>\n> Hmm, don't we have to say like all other reset types which paths are\n> dirty, i.e.\n>\n> $ git reset HEAD -- diff.c\n> Unstaged changes after reset:\n> M diff.c\n> M diff.h\n>\n> which would mean we would need to refresh the index anyway?\n\nThis reminder is handy, but I can understand that people with really big\ntrees whish to stat all the files only as needed (and would need to run\n\"git status\" by hand when needed). We can imagine a config variable like\ncore.IHaveAReallyBigTree or so disabled by default for such cases.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"169086","messageId":"7v62oqignm.fsf@alter.siamese.dyndns.org","threadId":"27511","inReplyTo":"20110531212639.GA13234@sigill.intra.peff.net","subject":"Re: speed of git reset -- file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-31T23:39:25Z","receivedAt":"2011-05-31T23:39:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> ... Unfortunately this seems to trash the index (see the\n> comment there), and we end up having to refresh it.\n\nI think you are reading it wrong. Yes, diff-index will contaminate the\nin-core index when it tries to find out which paths are to be reset, the\n\"discard\" refers to the fact that it would be useless to add_cache_entry()\nor remove_file_from_cache() to the in-core index without reading the in-core\nindex afresh.\n\nSo we restart from a freshly read index (see read_cache() at the beginning\nof update_index_from_diff() callback) with all the stat information just\nas fresh as you used to have before you ran this \"git reset\", and then we\nupdate the paths that the internal diff-index found in the in-core index.\n\n\"git reset\" has always refreshed the index. If somebody _really_ wants to\nintroduce a slight inconsistency to \"git reset\" so that only in \"per-path\"\nmode it doesn't refresh, the call to refresh_index() can easily be removed\nfrom update_index_refresh(). There is no \"we end up having to\".\n\nIOW, we refresh by choice, design and inertia ;-).\n"},{"id":"169092","messageId":"BANLkTi=9Z6DKmR=1WesrA1kg0a0TVTaAQQ@mail.gmail.com","threadId":"27511","inReplyTo":"vpqr57e1pt8.fsf@bauges.imag.fr","subject":"Re: speed of git reset -- file","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-06-01T01:14:19Z","receivedAt":"2011-06-01T01:14:19Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Jun 1, 2011 at 5:13 AM, Matthieu Moy\n wrote:\n> This reminder is handy, but I can understand that people with really big\n> trees whish to stat all the files only as needed (and would need to run\n> \"git status\" by hand when needed). We can imagine a config variable like\n> core.IHaveAReallyBigTree or so disabled by default for such cases.\n\ngit update-index --assume-unchanged and core.ignorestat?\n-- \nDuy\n"},{"id":"169146","messageId":"20110601195831.GA30070@sigill.intra.peff.net","threadId":"27511","inReplyTo":"7v62oqignm.fsf@alter.siamese.dyndns.org","subject":"Re: speed of git reset -- file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-06-01T19:58:31Z","receivedAt":"2011-06-01T19:58:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, May 31, 2011 at 04:39:25PM -0700, Junio C Hamano wrote:\n\n> \"git reset\" has always refreshed the index. If somebody _really_ wants to\n> introduce a slight inconsistency to \"git reset\" so that only in \"per-path\"\n> mode it doesn't refresh, the call to refresh_index() can easily be removed\n> from update_index_refresh(). There is no \"we end up having to\".\n> \n> IOW, we refresh by choice, design and inertia ;-).\n\nAh, yeah, I really wasn't thinking of the fact that refreshing is a\nuser-facing operation. These days most of the porcelain commands will do\nit for you automatically, so it's easy to forget.\n\nSo implementing the \"optimization\" to drop the refresh here doesn't seem\nworth it. It inroduces an awful inconsistency, and it probably isn't\nsaving much in practice. Lots of other commands will end up stat'ing\neverything, anyway. Users with giant repos or slow stat calls are\nprobably better off using assume-unchanged, which would help this and\nmany other situations.\n\n-Peff\n"},{"id":"169147","messageId":"20110601201629.GA25354@gnu.kitenet.net","threadId":"27511","inReplyTo":"20110601195831.GA30070@sigill.intra.peff.net","subject":"Re: speed of git reset -- file","fromName":"Joey Hess","fromEmail":"joey@kitenet.net","sentAt":"2011-06-01T20:16:29Z","receivedAt":"2011-06-01T20:16:29Z","isPatch":false,"sender":{"key":"joey@kitenet.net","avatar":"https://avatars.githubusercontent.com/u/16392?v=4"},"body":"Jeff King wrote:\n> So implementing the \"optimization\" to drop the refresh here doesn't seem\n> worth it. It inroduces an awful inconsistency, and it probably isn't\n> saving much in practice. Lots of other commands will end up stat'ing\n> everything, anyway. Users with giant repos or slow stat calls are\n> probably better off using assume-unchanged, which would help this and\n> many other situations.\n\nSounded like git-reset -q file could be optimised to not reread the\nindex without any visible inconsistency?\n\nMy experience with semi-large trees[1] is that I have to remember to use\n\"git status .\" in a subdir; that \"git commit -a\" is of course slow when\nI need to use it; and that the index gets big and things that need to\nupdate it can become somewhat slow especially on slow disks, but that\notherwise git scales fairly well and has good locality, and that it's\neasy to reason about what operations are global and avoid them.\nSo this git-reset behavior was surprising.\n\nassume-unchanged seems like it would add a lot of work when merging.\n\n-- \nsee shy jo\n\n[1] Two or three times the number of files as linux-2.6.\n"},{"id":"169148","messageId":"7vvcwpff6o.fsf@alter.siamese.dyndns.org","threadId":"27511","inReplyTo":"20110601195831.GA30070@sigill.intra.peff.net","subject":"Re: speed of git reset -- file","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-06-01T20:51:43Z","receivedAt":"2011-06-01T20:51:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> So implementing the \"optimization\" to drop the refresh here doesn't seem\n> worth it. It inroduces an awful inconsistency, and it probably isn't\n> saving much in practice...\n\nYou could make it less inconsistent by introducing core.autorefreshindex\nfor people who _do_ care about the latency. We already have a precedent in\ndiff.autorefreshindex and the new configuration would supercede it.\n\nUsually we refresh the cached lstat information in the index at strategic\nplaces so that later operations do not have to pay the penalty, but at the\nsame time, the higher level commands that want to make sure they are not\nfooled by stale lstat differences do refresh the index themselves anyway,\nso leaving cached stat information stale is not exactly the end of the\nworld.\n\nAll the high-level commands like \"reset\" that do _not_ absolutely need to\nrefresh the index for them to work, but do refresh the index to help later\ninvocation of other commands, could be taught to pay attention to the\ncore.autorefreshindex. After many operations the users usually do not see\nchanges from diff-files, people who set this to false will see phantom\nchanges due to stale cached lstat information, and they will see them\nconsistently. They know exactly when having up-to-date lstat information\nin the index really matters, and they will run \"update-index --refresh\"\nthemselves when needed.\n\nI however personally doubt it would be worth the effort. The _only_ person\nwho complained about this doesn't even use \"update-index --refresh\" but\nuses \"git status\", which does more than refreshing the index, and seems to\nthink the extra latency coming from the overhead is acceptable.\n\nSo...\n"},{"id":"169149","messageId":"20110601211847.GA31958@sigill.intra.peff.net","threadId":"27511","inReplyTo":"20110601201629.GA25354@gnu.kitenet.net","subject":"Re: speed of git reset -- file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-06-01T21:18:47Z","receivedAt":"2011-06-01T21:18:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 01, 2011 at 04:16:29PM -0400, Joey Hess wrote:\n\n> Jeff King wrote:\n> > So implementing the \"optimization\" to drop the refresh here doesn't seem\n> > worth it. It inroduces an awful inconsistency, and it probably isn't\n> > saving much in practice. Lots of other commands will end up stat'ing\n> > everything, anyway. Users with giant repos or slow stat calls are\n> > probably better off using assume-unchanged, which would help this and\n> > many other situations.\n> \n> Sounded like git-reset -q file could be optimised to not reread the\n> index without any visible inconsistency?\n\nNo, there would still be a visible inconsistency. For example:\n\n $ git reset -q -- file\n $ git diff-files\n\nmight leave stat-dirty entries in the index, but:\n\n $ git reset -- file\n $ git diff-files\n\nwould not.\n\nIn practice, it doesn't matter that much, because you would probably run\nthe porcelain \"git diff\" instead of the plumbing \"git diff-files\"\nanyway. And \"git diff\" refreshes the index itself, so the behavior\nchange is not that important. But then, as you see, we end up refreshing\nthe index defensively a lot, anyway, so saving the one refresh from\nreset may be lost in the noise (unless you are doing some tight loop of\nresets).\n\nSo what you could do with assume-unchanged (or much better, the\nautorefreshindex variable that Junio recommends), would be to shut off\n_all_ of the unnecessary refreshes, not just this one.\n\n> My experience with semi-large trees[1] is that I have to remember to use\n> \"git status .\" in a subdir; that \"git commit -a\" is of course slow when\n> I need to use it; and that the index gets big and things that need to\n> update it can become somewhat slow especially on slow disks, but that\n\nGenerally I find that the stats are very fast because everything is in\ncache, and the disk doesn't come into it at all. Are you on an OS\nbesides Linux, or on a machine with low memory?\n\n> otherwise git scales fairly well and has good locality, and that it's\n> easy to reason about what operations are global and avoid them.\n> So this git-reset behavior was surprising.\n\nYeah, git is generally very good about touching only the pieces of data\nyou need to complete the current operation. But I think the decision was\nmade long ago that \"update-index --refresh\" was not too expensive to do\nit in most porcelain-ish commands, especially since the results are much\nbetter (e.g., more accurately indicating modified files after a reset).\n\n> assume-unchanged seems like it would add a lot of work when merging.\n\nYeah, Junio's autorefresh suggestion is much better.\n\n-Peff\n"},{"id":"169152","messageId":"20110601220502.GA28493@gnu.kitenet.net","threadId":"27511","inReplyTo":"20110601211847.GA31958@sigill.intra.peff.net","subject":"Re: speed of git reset -- file","fromName":"Joey Hess","fromEmail":"joey@kitenet.net","sentAt":"2011-06-01T22:05:02Z","receivedAt":"2011-06-01T22:05:02Z","isPatch":false,"sender":{"key":"joey@kitenet.net","avatar":"https://avatars.githubusercontent.com/u/16392?v=4"},"body":"Jeff King wrote:\n> > My experience with semi-large trees[1] is that I have to remember to use\n> > \"git status .\" in a subdir; that \"git commit -a\" is of course slow when\n> > I need to use it; and that the index gets big and things that need to\n> > update it can become somewhat slow especially on slow disks, but that\n> \n> Generally I find that the stats are very fast because everything is in\n> cache, and the disk doesn't come into it at all. Are you on an OS\n> besides Linux, or on a machine with low memory?\n\nI have Linux and a gigabyte of ram and a not particularly good SSD.\nHere `git reset file` takes 30 seconds, `git status` 45 seconds.\n\nI do not seem to be alone in finding git reset file to be slow, the\nproblem was reported to me by another user.\n\n> Yeah, Junio's autorefresh suggestion is much better.\n\nThat did seem reasonable and something I'd probably use.\n\n-- \nsee shy jo\n"},{"id":"169165","messageId":"20110601225647.GD16820@sigill.intra.peff.net","threadId":"27511","inReplyTo":"20110601220502.GA28493@gnu.kitenet.net","subject":"Re: speed of git reset -- file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-06-01T22:56:48Z","receivedAt":"2011-06-01T22:56:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 01, 2011 at 06:05:02PM -0400, Joey Hess wrote:\n\n> Jeff King wrote:\n> > > My experience with semi-large trees[1] is that I have to remember to use\n> > > \"git status .\" in a subdir; that \"git commit -a\" is of course slow when\n> > > I need to use it; and that the index gets big and things that need to\n> > > update it can become somewhat slow especially on slow disks, but that\n> > \n> > Generally I find that the stats are very fast because everything is in\n> > cache, and the disk doesn't come into it at all. Are you on an OS\n> > besides Linux, or on a machine with low memory?\n> \n> I have Linux and a gigabyte of ram and a not particularly good SSD.\n> Here `git reset file` takes 30 seconds, `git status` 45 seconds.\n\nOK, that's horrific. For me, the stat information for linux-2.6 all sits\nin cache and it takes about 0.3 seconds to refresh the index. I have 8G\nof ram and a nice SSD, though it doesn't actually hit the disk at all.\n\nIs it really faulting the stat information from disk that takes so long?\nHave you tried running \"perf\" on \"git update-index --refresh\"?\n\n-Peff\n"},{"id":"169167","messageId":"20110601233157.GA2468@gnu.kitenet.net","threadId":"27511","inReplyTo":"20110601225647.GD16820@sigill.intra.peff.net","subject":"Re: speed of git reset -- file","fromName":"Joey Hess","fromEmail":"joey@kitenet.net","sentAt":"2011-06-01T23:31:57Z","receivedAt":"2011-06-01T23:31:57Z","isPatch":false,"sender":{"key":"joey@kitenet.net","avatar":"https://avatars.githubusercontent.com/u/16392?v=4"},"body":"Jeff King wrote:\n> OK, that's horrific. For me, the stat information for linux-2.6 all sits\n> in cache and it takes about 0.3 seconds to refresh the index. I have 8G\n> of ram and a nice SSD, though it doesn't actually hit the disk at all.\n> \n> Is it really faulting the stat information from disk that takes so long?\n> Have you tried running \"perf\" on \"git update-index --refresh\"?\n\nCold cache:\n\n Performance counter stats for 'git update-index --refresh':\n\n 9725.574501 task-clock-msecs # 0.337 CPUs \n 58,163 context-switches # 0.006 M/sec\n 94 CPU-migrations # 0.000 M/sec\n 8,637 page-faults # 0.001 M/sec\n 12,825,956,531 cycles # 1318.787 M/sec (scaled from 33.43%)\n 2,696,089,912 instructions # 0.210 IPC (scaled from 50.03%)\n 457,705,110 branches # 47.062 M/sec (scaled from 51.30%)\n 40,033,685 branch-misses # 8.747 % (scaled from 50.19%)\n 149,071,234 cache-references # 15.328 M/sec (scaled from 32.83%)\n 9,662,661 cache-misses # 0.994 M/sec (scaled from 32.27%)\n\n 28.846625099 seconds time elapsed\n\nWarm cache is 0.88 seconds, but cold cache is typical; I use a cheap netbook\nfor a lot of different stuff.\n\nAlso, I can get much worse cold cache numbers on eg, a fairly average\nVPS node, where it takes > 1 minute.\n\n-- \nsee shy jo\n"},{"id":"169169","messageId":"20110602031831.GA21008@sigill.intra.peff.net","threadId":"27511","inReplyTo":"20110601233157.GA2468@gnu.kitenet.net","subject":"Re: speed of git reset -- file","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-06-02T03:18:31Z","receivedAt":"2011-06-02T03:18:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jun 01, 2011 at 07:31:57PM -0400, Joey Hess wrote:\n\n> Cold cache:\n> [...]\n> 28.846625099 seconds time elapsed\n> \n> Warm cache is 0.88 seconds, but cold cache is typical; I use a cheap netbook\n> for a lot of different stuff.\n\nYeah, it is going to be painful on a cold cache. But I wonder whether\nyour workflow would really permit the \"reset\" thing to make a\ndifference. That is, are you doing \"git reset -- file\" from a cold\ncache, and then doing _nothing_ else with git? Because while yes, it may\nbe annoying for the \"reset\" to take 30 seconds, it's warming the cache\nso that the subsequent \"diff\" or \"status\" will take 29.1 seconds less.\n\nWhich isn't to say I'm not sympathetic to the performance problems of\nlarge repos on a cold cache. But I'm not sure there's really a way\naround that. You're going to want to see the stat information eventually\nif you are doing anything meaningful with git, and once it's loaded, the\nwarm cache delay isn't too bad. Trying to avoid it seems like a losing\nbattle.\n\n-Peff\n"},{"id":"169170","messageId":"20110602043630.GA5081@gnu.kitenet.net","threadId":"27511","inReplyTo":"20110602031831.GA21008@sigill.intra.peff.net","subject":"Re: speed of git reset -- file","fromName":"Joey Hess","fromEmail":"joey@kitenet.net","sentAt":"2011-06-02T04:36:30Z","receivedAt":"2011-06-02T04:36:30Z","isPatch":false,"sender":{"key":"joey@kitenet.net","avatar":"https://avatars.githubusercontent.com/u/16392?v=4"},"body":"Jeff King wrote:\n> Yeah, it is going to be painful on a cold cache. But I wonder whether\n> your workflow would really permit the \"reset\" thing to make a\n> difference. That is, are you doing \"git reset -- file\" from a cold\n> cache, and then doing _nothing_ else with git? Because while yes, it may\n> be annoying for the \"reset\" to take 30 seconds, it's warming the cache\n> so that the subsequent \"diff\" or \"status\" will take 29.1 seconds less.\n> \n> Which isn't to say I'm not sympathetic to the performance problems of\n> large repos on a cold cache. But I'm not sure there's really a way\n> around that. You're going to want to see the stat information eventually\n> if you are doing anything meaningful with git, and once it's loaded, the\n> warm cache delay isn't too bad. Trying to avoid it seems like a losing\n> battle.\n\nCould be true in general. While I've gotten the reset out of this\nworkflow (realized I could just `git checkout HEAD file` and that would\nalso clear staged changes), in this case it was actually *unlikely* that\nthe cache would be unused, as I was resetting to throw unwanted changes\naway.\n\n-- \nsee shy jo\n"},{"id":"169174","messageId":"20110602044638.GC5081@gnu.kitenet.net","threadId":"27511","inReplyTo":"20110602043630.GA5081@gnu.kitenet.net","subject":"Re: speed of git reset -- file","fromName":"Joey Hess","fromEmail":"joey@kitenet.net","sentAt":"2011-06-02T04:46:38Z","receivedAt":"2011-06-02T04:46:38Z","isPatch":false,"sender":{"key":"joey@kitenet.net","avatar":"https://avatars.githubusercontent.com/u/16392?v=4"},"body":"Joey Hess wrote:\n> Jeff King wrote:\n> > Yeah, it is going to be painful on a cold cache. But I wonder whether\n> > your workflow would really permit the \"reset\" thing to make a\n> > difference. That is, are you doing \"git reset -- file\" from a cold\n> > cache, and then doing _nothing_ else with git? Because while yes, it may\n> > be annoying for the \"reset\" to take 30 seconds, it's warming the cache\n> > so that the subsequent \"diff\" or \"status\" will take 29.1 seconds less.\n> > \n> > Which isn't to say I'm not sympathetic to the performance problems of\n> > large repos on a cold cache. But I'm not sure there's really a way\n> > around that. You're going to want to see the stat information eventually\n> > if you are doing anything meaningful with git, and once it's loaded, the\n> > warm cache delay isn't too bad. Trying to avoid it seems like a losing\n> > battle.\n> \n> Could be true in general. While I've gotten the reset out of this\n> workflow (realized I could just `git checkout HEAD file` and that would\n> also clear staged changes), in this case it was actually *unlikely* that\n> the cache would be unused, as I was resetting to throw unwanted changes\n> away.\n\nTypo, meant to say unlikly that the cache would be used.\n\n-- \nsee shy jo\n"}]}