{"thread":{"id":"45858","subject":"RFA: untracked cache vs git reset --hard","startedAt":"2017-05-03T10:27:15Z","lastAt":"2017-05-03T10:55:38Z","messageCount":2,"participants":["Johannes Schindelin","Duy Nguyen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"318640","messageId":"alpine.DEB.2.20.1705031202470.3480@virtualbox","threadId":"45858","inReplyTo":null,"subject":"RFA: untracked cache vs git reset --hard","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-05-03T10:27:00Z","receivedAt":"2017-05-03T10:27:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi all,\n\nI have a problem and would like to solicit advice how to fix it.\n\nThe untracked cache has made a real difference on rather large\nrepositories with tons of directories, and it is really, really useful.\n\nBut. One innocuous `git reset --hard` will just blow it away.\n\nHow? reset_index() calls unpack_trees() which in turn tries to populate a\nnew index and then discards the old one:\n\n\thttps://github.com/git/git/blob/v2.12.2/unpack-trees.c#L1293\n\nThat discard_index() unfortunately also blows away each and every index\nextension that had been read carefully before.\n\nAll users of `git reset --hard` (including `git stash`) suffer this.\n\nIn fact, it looks as if *any* caller of unpack_trees() would suffer the\nsame problem: git-am, git-checkout, git-commit, git-merge, etc\n\nNow, I could imagine that maybe we could just \"move\"\no->dst_index.untracked to o->result.untracked, and that the machinery then\nwould do the right thing.\n\nHowever, I am far from an expert in this area, so I would appreciate all\nthe helpful advice I could get.\n\nThoughts?\n\nThanks,\nJohannes\n"},{"id":"318642","messageId":"CACsJy8BasKLSuMuoqT1MNWbp93qxuG1Z+auiM6SaN7fBYT8sFw@mail.gmail.com","threadId":"45858","inReplyTo":"alpine.DEB.2.20.1705031202470.3480@virtualbox","subject":"Re: RFA: untracked cache vs git reset --hard","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2017-05-03T10:54:49Z","receivedAt":"2017-05-03T10:55:38Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, May 3, 2017 at 5:27 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi all,\n>\n> I have a problem and would like to solicit advice how to fix it.\n>\n> The untracked cache has made a real difference on rather large\n> repositories with tons of directories, and it is really, really useful.\n>\n> But. One innocuous `git reset --hard` will just blow it away.\n>\n> How? reset_index() calls unpack_trees() which in turn tries to populate a\n> new index and then discards the old one:\n>\n>         https://github.com/git/git/blob/v2.12.2/unpack-trees.c#L1293\n>\n> That discard_index() unfortunately also blows away each and every index\n> extension that had been read carefully before.\n\nThis is a real problem when we introduce non-optional extensions (i.e.\nextension name in lower case). Dropping them is not an option because\nthey may contain vital/original information. We haven't any so far,\nbut I've been wanting to add one for years (narrow clone). So I'm all\nfor tackling the problem now :)\n\n> All users of `git reset --hard` (including `git stash`) suffer this.\n>\n> In fact, it looks as if *any* caller of unpack_trees() would suffer the\n> same problem: git-am, git-checkout, git-commit, git-merge, etc\n>\n> Now, I could imagine that maybe we could just \"move\"\n> o->dst_index.untracked to o->result.untracked, and that the machinery then\n> would do the right thing.\n\nThese extensions may have dependencies in the o->result.cache[] (do we\nallow an extension to depend on another?). If invalidation is not\nhandled correctly then it's not safe to simply copy the extension\nover.\n\nFor untracked cache, I think we do invalidation right and just moving\nit over dst_index (and resetting NULL in o->result so it does not get\naccidentally deleted) is fine.\n\nI'd rather we have a common way of dealing with this for any extension\nthough. Split index needs special treatment too [1]. Maybe we can add\n\nint migrate_index_extensions(struct index_state *dst, struct index_state *src);\n\nin read-cache.c where it calls migrate_XXX() for each extension. In\nsome cases (cache-tree) we could even do more, like repair cache-tree\nthere to avoid hitting performance regressions.\n\n[1] https://github.com/git/git/blob/v2.12.2/unpack-trees.c#L1165-L1167\n-- \nDuy\n"}]}