{"thread":{"id":"47171","subject":"[PATCH] mru: Replace mru.[ch] with list.h implementation","startedAt":"2017-11-11T18:08:13Z","lastAt":"2017-12-12T14:08:29Z","messageCount":6,"participants":["Gargi Sharma","Jeff King","Оля Тележная"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"332300","messageId":"1510423606-9616-1-git-send-email-gs051095@gmail.com","threadId":"47171","inReplyTo":null,"subject":"[PATCH] mru: Replace mru.[ch] with list.h implementation","fromName":"Gargi Sharma","fromEmail":"gs051095@gmail.com","sentAt":"2017-11-11T18:06:46Z","receivedAt":"2017-11-11T18:08:13Z","isPatch":true,"sender":{"key":"gs051095@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8718814?v=4"},"body":"Replace custom allocation in mru.[ch] with generic calls\nto list.h API.\n\nSigned-off-by: Gargi Sharma <gs051095@gmail.com>\n---\n builtin/pack-objects.c | 14 ++++++++------\n cache.h                |  9 +++++----\n mru.c                  | 27 ---------------------------\n mru.h                  | 40 ----------------------------------------\n packfile.c             | 28 +++++++++++++++++++---------\n 5 files changed, 32 insertions(+), 86 deletions(-)\n delete mode 100644 mru.c\n delete mode 100644 mru.h\n\ndiff --git a/builtin/pack-objects.c b/builtin/pack-objects.c\nindex ba81234..26717c5 100644\n--- a/builtin/pack-objects.c\n+++ b/builtin/pack-objects.c\n@@ -24,7 +24,7 @@\n #include \"reachable.h\"\n #include \"sha1-array.h\"\n #include \"argv-array.h\"\n-#include \"mru.h\"\n+#include \"list.h\"\n #include \"packfile.h\"\n \n static const char *pack_usage[] = {\n@@ -1012,9 +1012,9 @@ static int want_object_in_pack(const unsigned char *sha1,\n \t\t\treturn want;\n \t}\n \n-\tlist_for_each(pos, &packed_git_mru.list) {\n-\t\tstruct mru *entry = list_entry(pos, struct mru, list);\n-\t\tstruct packed_git *p = entry->item;\n+\tlist_for_each(pos, &packed_git_mru) {\n+\t\tstruct packed_git *p = list_entry(pos, struct packed_git, mru);\n+\t\tstruct list_head *entry = &(p->mru);\n \t\toff_t offset;\n \n \t\tif (p == *found_pack)\n@@ -1030,8 +1030,10 @@ static int want_object_in_pack(const unsigned char *sha1,\n \t\t\t\t*found_pack = p;\n \t\t\t}\n \t\t\twant = want_found_object(exclude, p);\n-\t\t\tif (!exclude && want > 0)\n-\t\t\t\tmru_mark(&packed_git_mru, entry);\n+\t\t\tif (!exclude && want > 0) {\n+\t\t\t\tlist_del(entry);\n+\t\t\t\tlist_add(entry, &packed_git_mru);\n+\t\t\t}\n \t\t\tif (want != -1)\n \t\t\t\treturn want;\n \t\t}\ndiff --git a/cache.h b/cache.h\nindex 49b083e..1a275ae 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -4,7 +4,7 @@\n #include \"git-compat-util.h\"\n #include \"strbuf.h\"\n #include \"hashmap.h\"\n-#include \"mru.h\"\n+#include \"list.h\"\n #include \"advice.h\"\n #include \"gettext.h\"\n #include \"convert.h\"\n@@ -1566,6 +1566,7 @@ struct pack_window {\n \n extern struct packed_git {\n \tstruct packed_git *next;\n+\tstruct list_head mru;\n \tstruct pack_window *windows;\n \toff_t pack_size;\n \tconst void *index_data;\n@@ -1587,10 +1588,10 @@ extern struct packed_git {\n } *packed_git;\n \n /*\n- * A most-recently-used ordered version of the packed_git list, which can\n- * be iterated instead of packed_git (and marked via mru_mark).\n+ * A most-recently-used ordered version of the packed_git list.\n  */\n-extern struct mru packed_git_mru;\n+extern struct list_head packed_git_mru;\n+\n \n struct pack_entry {\n \toff_t offset;\ndiff --git a/mru.c b/mru.c\ndeleted file mode 100644\nindex 8f3f34c..0000000\n--- a/mru.c\n+++ /dev/null\n@@ -1,27 +0,0 @@\n-#include \"cache.h\"\n-#include \"mru.h\"\n-\n-void mru_append(struct mru *head, void *item)\n-{\n-\tstruct mru *cur = xmalloc(sizeof(*cur));\n-\tcur->item = item;\n-\tlist_add_tail(&cur->list, &head->list);\n-}\n-\n-void mru_mark(struct mru *head, struct mru *entry)\n-{\n-\t/* To mark means to put at the front of the list. */\n-\tlist_del(&entry->list);\n-\tlist_add(&entry->list, &head->list);\n-}\n-\n-void mru_clear(struct mru *head)\n-{\n-\tstruct list_head *pos;\n-\tstruct list_head *tmp;\n-\n-\tlist_for_each_safe(pos, tmp, &head->list) {\n-\t\tfree(list_entry(pos, struct mru, list));\n-\t}\n-\tINIT_LIST_HEAD(&head->list);\n-}\ndiff --git a/mru.h b/mru.h\ndeleted file mode 100644\nindex 80a589e..0000000\n--- a/mru.h\n+++ /dev/null\n@@ -1,40 +0,0 @@\n-#ifndef MRU_H\n-#define MRU_H\n-\n-#include \"list.h\"\n-\n-/**\n- * A simple most-recently-used cache, backed by a doubly-linked list.\n- *\n- * Usage is roughly:\n- *\n- *   // Create a list.  Zero-initialization is required.\n- *   static struct mru cache;\n- *   INIT_LIST_HEAD(&cache.list);\n- *\n- *   // Add new item to the end of the list.\n- *   void *item;\n- *   ...\n- *   mru_append(&cache, item);\n- *\n- *   // Mark an item as used, moving it to the front of the list.\n- *   mru_mark(&cache, item);\n- *\n- *   // Reset the list to empty, cleaning up all resources.\n- *   mru_clear(&cache);\n- *\n- * Note that you SHOULD NOT call mru_mark() and then continue traversing the\n- * list; it reorders the marked item to the front of the list, and therefore\n- * you will begin traversing the whole list again.\n- */\n-\n-struct mru {\n-\tstruct list_head list;\n-\tvoid *item;\n-};\n-\n-void mru_append(struct mru *head, void *item);\n-void mru_mark(struct mru *head, struct mru *entry);\n-void mru_clear(struct mru *head);\n-\n-#endif /* MRU_H */\ndiff --git a/packfile.c b/packfile.c\nindex 502d915..3882d0b 100644\n--- a/packfile.c\n+++ b/packfile.c\n@@ -1,5 +1,5 @@\n #include \"cache.h\"\n-#include \"mru.h\"\n+#include \"list.h\"\n #include \"pack.h\"\n #include \"dir.h\"\n #include \"mergesort.h\"\n@@ -40,7 +40,7 @@ static unsigned int pack_max_fds;\n static size_t peak_pack_mapped;\n static size_t pack_mapped;\n struct packed_git *packed_git;\n-struct mru packed_git_mru = {{&packed_git_mru.list, &packed_git_mru.list}};\n+LIST_HEAD(packed_git_mru);\n \n #define SZ_FMT PRIuMAX\n static inline uintmax_t sz_fmt(size_t s) { return s; }\n@@ -859,9 +859,18 @@ static void prepare_packed_git_mru(void)\n {\n \tstruct packed_git *p;\n \n-\tmru_clear(&packed_git_mru);\n-\tfor (p = packed_git; p; p = p->next)\n-\t\tmru_append(&packed_git_mru, p);\n+\tstruct list_head *pos;\n+\tstruct list_head *tmp;\n+\tlist_for_each_safe(pos, tmp, &packed_git_mru)\n+\t\tlist_del_init(pos);\n+\n+\tINIT_LIST_HEAD(&packed_git_mru);\n+\n+\tfor (p = packed_git; p; p = p->next) {\n+\t\tstruct packed_git *cur = xmalloc(sizeof(*packed_git));\n+\t\tcur = p;\n+\t\tlist_add_tail(&cur->mru, &packed_git_mru);\n+\t}\n }\n \n static int prepare_packed_git_run_once = 0;\n@@ -1830,10 +1839,11 @@ int find_pack_entry(const unsigned char *sha1, struct pack_entry *e)\n \tif (!packed_git)\n \t\treturn 0;\n \n-\tlist_for_each(pos, &packed_git_mru.list) {\n-\t\tstruct mru *p = list_entry(pos, struct mru, list);\n-\t\tif (fill_pack_entry(sha1, e, p->item)) {\n-\t\t\tmru_mark(&packed_git_mru, p);\n+\tlist_for_each(pos, &packed_git_mru) {\n+\t\tstruct packed_git *p = list_entry(pos, struct packed_git, mru);\n+\t\tif (fill_pack_entry(sha1, e, p)) {\n+\t\t\tlist_del(&p->mru);\n+\t\t\tlist_add(&p->mru, &packed_git_mru);\n \t\t\treturn 1;\n \t\t}\n \t}\n-- \n2.7.4\n\n"},{"id":"332315","messageId":"20171112095435.f4o662ygtt2taf5y@sigill.intra.peff.net","threadId":"47171","inReplyTo":"1510423606-9616-1-git-send-email-gs051095@gmail.com","subject":"Re: [PATCH] mru: Replace mru.[ch] with list.h implementation","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-11-12T09:54:36Z","receivedAt":"2017-11-12T09:54:46Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Nov 11, 2017 at 01:06:46PM -0500, Gargi Sharma wrote:\n\n> Replace custom allocation in mru.[ch] with generic calls\n> to list.h API.\n> \n> Signed-off-by: Gargi Sharma <gs051095@gmail.com>\n\nThanks, and welcome to the git list. :)\n\nThis looks like a good start on the topic, but I have a few comments.\n\nIt's a good idea to explain in the commit message not just what we're\ndoing, but why we want to do it, to help later readers of \"git log\". I\nknow that you picked this up from the discussion in the thread at:\n\n  https://public-inbox.org/git/xmqq8tgz13x7.fsf@gitster.mtv.corp.google.com/\n\nso it might be a good idea to summarize the ideas there (and add your\nown thoughts, of course).\n\n> ---\n>  builtin/pack-objects.c | 14 ++++++++------\n>  cache.h                |  9 +++++----\n>  mru.c                  | 27 ---------------------------\n>  mru.h                  | 40 ----------------------------------------\n>  packfile.c             | 28 +++++++++++++++++++---------\n>  5 files changed, 32 insertions(+), 86 deletions(-)\n>  delete mode 100644 mru.c\n>  delete mode 100644 mru.h\n\nAfter the \"---\" line, you can put any information that people on the\nlist might want to know but that doesn't need to go into the commit\nmessage. The big thing the maintainer would want to know here is that\nyour patch is prepared on top of the ot/mru-on-list topic, so he knows\nwhere to apply it.\n\nThe diffstat is certainly encouraging so far. :)\n\n> @@ -1012,9 +1012,9 @@ static int want_object_in_pack(const unsigned char *sha1,\n>  \t\t\treturn want;\n>  \t}\n>  \n> -\tlist_for_each(pos, &packed_git_mru.list) {\n> -\t\tstruct mru *entry = list_entry(pos, struct mru, list);\n> -\t\tstruct packed_git *p = entry->item;\n> +\tlist_for_each(pos, &packed_git_mru) {\n> +\t\tstruct packed_git *p = list_entry(pos, struct packed_git, mru);\n> +\t\tstruct list_head *entry = &(p->mru);\n>  \t\toff_t offset;\n>  \n>  \t\tif (p == *found_pack)\n\nI think \"entry\" here is going to be the same as \"pos\". That said, I\nthink it's only use is in bumping us to the front of the mru list later:\n\n> @@ -1030,8 +1030,10 @@ static int want_object_in_pack(const unsigned char *sha1,\n>  \t\t\t\t*found_pack = p;\n>  \t\t\t}\n>  \t\t\twant = want_found_object(exclude, p);\n> -\t\t\tif (!exclude && want > 0)\n> -\t\t\t\tmru_mark(&packed_git_mru, entry);\n> +\t\t\tif (!exclude && want > 0) {\n> +\t\t\t\tlist_del(entry);\n> +\t\t\t\tlist_add(entry, &packed_git_mru);\n> +\t\t\t}\n\nAnd I think this might be more obvious if we drop \"entry\" entirely and\njust do:\n\n  list_del(&p->mru);\n  list_add(&p->mru, &packed_git_mru);\n\nIt might merit a comment like \"/* bump to the front of the mru list */\"\nor similar to make it clear what's going on (or even adding a\nlist_move_to_front() helper).\n\n> @@ -1566,6 +1566,7 @@ struct pack_window {\n>  \n>  extern struct packed_git {\n>  \tstruct packed_git *next;\n> +\tstruct list_head mru;\n>  \tstruct pack_window *windows;\n>  \toff_t pack_size;\n>  \tconst void *index_data;\n\nSort of a side note, but seeing these two list pointers together makes\nme wonder what we should do with the list created by the \"next\" pointer.\nIt seems like there are three options:\n\n  1. Convert it to \"struct list_head\", too, for consistency.\n\n  2. Leave it as-is. We never delete from the list nor do any fancy\n     manipulation, so it doesn't benefit from the reusable code.\n\n  3. I wonder if we could drop it entirely, and just keep a single list\n     of packs, ordered by mru. I'm not sure if anybody actually cares\n     about accessing them in the \"original\" order. That order is\n     reverse-chronological (by prepare_packed_git()), but I think that\n     was mostly out of a sense that recent packs would be accessed more\n     than older ones (but having a real mru strategy replaces that\n     anyway).\n\nWhat do you think?\n\n> diff --git a/mru.c b/mru.c\n> deleted file mode 100644\n> index 8f3f34c..0000000\n\nYay, this hunk (and the one for mru.h) is satisfying.\n\n> @@ -40,7 +40,7 @@ static unsigned int pack_max_fds;\n>  static size_t peak_pack_mapped;\n>  static size_t pack_mapped;\n>  struct packed_git *packed_git;\n> -struct mru packed_git_mru = {{&packed_git_mru.list, &packed_git_mru.list}};\n> +LIST_HEAD(packed_git_mru);\n\nMuch nicer.\n\n> @@ -859,9 +859,18 @@ static void prepare_packed_git_mru(void)\n>  {\n>  \tstruct packed_git *p;\n>  \n> -\tmru_clear(&packed_git_mru);\n> -\tfor (p = packed_git; p; p = p->next)\n> -\t\tmru_append(&packed_git_mru, p);\n> +\tstruct list_head *pos;\n> +\tstruct list_head *tmp;\n> +\tlist_for_each_safe(pos, tmp, &packed_git_mru)\n> +\t\tlist_del_init(pos);\n\nThis matches the original code, which did the clear/re-create, resetting\nthe mru to the \"original\" pack order. But I do wonder if that's actually\nnecessary. Could we skip that and just add any new packs to the list?\n\nThat goes hand-in-hand with the idea of dropping the \"next\" pointer that\nI mentioned above.\n\n> +\tINIT_LIST_HEAD(&packed_git_mru);\n\nI think this INIT_LIST_HEAD() isn't necessary anymore. In the original\ncode, we just freed each of the mru_entry structs, which meant we had to\nforcibly reset the list head to be empty. But here you've used\nlist_del_init(), so after deleting everything, packed_git_mru should\nalready be empty.\n\n> +\tfor (p = packed_git; p; p = p->next) {\n> +\t\tstruct packed_git *cur = xmalloc(sizeof(*packed_git));\n> +\t\tcur = p;\n> +\t\tlist_add_tail(&cur->mru, &packed_git_mru);\n> +\t}\n\nThis malloc can go away. The original mru code kept a separate entry,\nbut now we don't need that. So here you're just leaking it when you\nassign \"cur = p\" (in fact, I think you can get rid of cur entirely).\n\n> @@ -1830,10 +1839,11 @@ int find_pack_entry(const unsigned char *sha1, struct pack_entry *e)\n>  \tif (!packed_git)\n>  \t\treturn 0;\n>  \n> -\tlist_for_each(pos, &packed_git_mru.list) {\n> -\t\tstruct mru *p = list_entry(pos, struct mru, list);\n> -\t\tif (fill_pack_entry(sha1, e, p->item)) {\n> -\t\t\tmru_mark(&packed_git_mru, p);\n> +\tlist_for_each(pos, &packed_git_mru) {\n> +\t\tstruct packed_git *p = list_entry(pos, struct packed_git, mru);\n> +\t\tif (fill_pack_entry(sha1, e, p)) {\n> +\t\t\tlist_del(&p->mru);\n> +\t\t\tlist_add(&p->mru, &packed_git_mru);\n>  \t\t\treturn 1;\n>  \t\t}\n>  \t}\n\nAnd this hunk looks pretty good (though if we added a move-to-front\nhelper, it could be used here, too).\n\n-Peff\n"},{"id":"332317","messageId":"20171112095910.xwz43bzfbr5hz3tq@sigill.intra.peff.net","threadId":"47171","inReplyTo":"20171112095435.f4o662ygtt2taf5y@sigill.intra.peff.net","subject":"Re: [PATCH] mru: Replace mru.[ch] with list.h implementation","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-11-12T09:59:10Z","receivedAt":"2017-11-12T09:59:18Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 12, 2017 at 09:54:35AM +0000, Jeff King wrote:\n\n> > @@ -1566,6 +1566,7 @@ struct pack_window {\n> >  \n> >  extern struct packed_git {\n> >  \tstruct packed_git *next;\n> > +\tstruct list_head mru;\n> >  \tstruct pack_window *windows;\n> >  \toff_t pack_size;\n> >  \tconst void *index_data;\n> \n> Sort of a side note, but seeing these two list pointers together makes\n> me wonder what we should do with the list created by the \"next\" pointer.\n> It seems like there are three options:\n> \n>   1. Convert it to \"struct list_head\", too, for consistency.\n> \n>   2. Leave it as-is. We never delete from the list nor do any fancy\n>      manipulation, so it doesn't benefit from the reusable code.\n> \n>   3. I wonder if we could drop it entirely, and just keep a single list\n>      of packs, ordered by mru. I'm not sure if anybody actually cares\n>      about accessing them in the \"original\" order. That order is\n>      reverse-chronological (by prepare_packed_git()), but I think that\n>      was mostly out of a sense that recent packs would be accessed more\n>      than older ones (but having a real mru strategy replaces that\n>      anyway).\n> \n> What do you think?\n\nThinking on this a bit more, even if we want to go down any road except\n(2), it probably ought to come as a separate patch on top anyway. The\nchanges you're making here are quite obviously a noop for visible\nbehavior.\n\nBut dropping the \"next\" pointer (and the matching \"don't clear the list\"\nI mentioned later) would potentially mean examining the packs in a\nslightly different order. I _think_ that's fine, but it's possible there\ncould be a subtle fallout. So it's better to keep it separate from the\nmore pure refactoring in your patch.\n\n-Peff\n"},{"id":"332323","messageId":"CAOCi2DGYQr4jFf5ObY2buyhNJeaAPQKF8tbojn2W0b18Eo+Wgw@mail.gmail.com","threadId":"47171","inReplyTo":"20171112095435.f4o662ygtt2taf5y@sigill.intra.peff.net","subject":"Re: [PATCH] mru: Replace mru.[ch] with list.h implementation","fromName":"Gargi Sharma","fromEmail":"gs051095@gmail.com","sentAt":"2017-11-12T12:49:17Z","receivedAt":"2017-11-12T12:49:54Z","isPatch":true,"sender":{"key":"gs051095@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8718814?v=4"},"body":"On Sun, Nov 12, 2017 at 9:54 AM, Jeff King <peff@peff.net> wrote:\n> On Sat, Nov 11, 2017 at 01:06:46PM -0500, Gargi Sharma wrote:\n>\n>> Replace custom allocation in mru.[ch] with generic calls\n>> to list.h API.\n>>\n>> Signed-off-by: Gargi Sharma <gs051095@gmail.com>\n>\n> Thanks, and welcome to the git list. :)\n>\n> This looks like a good start on the topic, but I have a few comments.\n>\n> It's a good idea to explain in the commit message not just what we're\n> doing, but why we want to do it, to help later readers of \"git log\". I\n> know that you picked this up from the discussion in the thread at:\n>\n>   https://public-inbox.org/git/xmqq8tgz13x7.fsf@gitster.mtv.corp.google.com/\n>\n> so it might be a good idea to summarize the ideas there (and add your\n> own thoughts, of course).\n>\n>> ---\n>>  builtin/pack-objects.c | 14 ++++++++------\n>>  cache.h                |  9 +++++----\n>>  mru.c                  | 27 ---------------------------\n>>  mru.h                  | 40 ----------------------------------------\n>>  packfile.c             | 28 +++++++++++++++++++---------\n>>  5 files changed, 32 insertions(+), 86 deletions(-)\n>>  delete mode 100644 mru.c\n>>  delete mode 100644 mru.h\n>\n> After the \"---\" line, you can put any information that people on the\n> list might want to know but that doesn't need to go into the commit\n> message. The big thing the maintainer would want to know here is that\n> your patch is prepared on top of the ot/mru-on-list topic, so he knows\n> where to apply it.\n>\n> The diffstat is certainly encouraging so far. :)\n>\n>> @@ -1012,9 +1012,9 @@ static int want_object_in_pack(const unsigned char *sha1,\n>>                       return want;\n>>       }\n>>\n>> -     list_for_each(pos, &packed_git_mru.list) {\n>> -             struct mru *entry = list_entry(pos, struct mru, list);\n>> -             struct packed_git *p = entry->item;\n>> +     list_for_each(pos, &packed_git_mru) {\n>> +             struct packed_git *p = list_entry(pos, struct packed_git, mru);\n>> +             struct list_head *entry = &(p->mru);\n>>               off_t offset;\n>>\n>>               if (p == *found_pack)\n>\n> I think \"entry\" here is going to be the same as \"pos\". That said, I\n> think it's only use is in bumping us to the front of the mru list later:\n>\n>> @@ -1030,8 +1030,10 @@ static int want_object_in_pack(const unsigned char *sha1,\n>>                               *found_pack = p;\n>>                       }\n>>                       want = want_found_object(exclude, p);\n>> -                     if (!exclude && want > 0)\n>> -                             mru_mark(&packed_git_mru, entry);\n>> +                     if (!exclude && want > 0) {\n>> +                             list_del(entry);\n>> +                             list_add(entry, &packed_git_mru);\n>> +                     }\n>\n> And I think this might be more obvious if we drop \"entry\" entirely and\n> just do:\n>\n>   list_del(&p->mru);\n>   list_add(&p->mru, &packed_git_mru);\n>\n> It might merit a comment like \"/* bump to the front of the mru list */\"\n> or similar to make it clear what's going on (or even adding a\n> list_move_to_front() helper).\n\nI will add a helper to list.h, for doing this :)\n>\n>> @@ -1566,6 +1566,7 @@ struct pack_window {\n>>\n>>  extern struct packed_git {\n>>       struct packed_git *next;\n>> +     struct list_head mru;\n>>       struct pack_window *windows;\n>>       off_t pack_size;\n>>       const void *index_data;\n>\n> Sort of a side note, but seeing these two list pointers together makes\n> me wonder what we should do with the list created by the \"next\" pointer.\n> It seems like there are three options:\n>\n>   1. Convert it to \"struct list_head\", too, for consistency.\n>\n>   2. Leave it as-is. We never delete from the list nor do any fancy\n>      manipulation, so it doesn't benefit from the reusable code.\n>\n>   3. I wonder if we could drop it entirely, and just keep a single list\n>      of packs, ordered by mru. I'm not sure if anybody actually cares\n>      about accessing them in the \"original\" order. That order is\n>      reverse-chronological (by prepare_packed_git()), but I think that\n>      was mostly out of a sense that recent packs would be accessed more\n>      than older ones (but having a real mru strategy replaces that\n>      anyway).\n>\n> What do you think?\nI think in the long run, it'll be easier if there is only a single\nlist of packs given\nthat no one needs to access the list in order.\n\nIf we go down road 1/3, would it be better if I sent an entirely\ndifferent patch or\na patch series with patch 1 as removing mru[.ch] and patch 2 as removing\nnext pointer from the struct?\n\n>\n>> diff --git a/mru.c b/mru.c\n>> deleted file mode 100644\n>> index 8f3f34c..0000000\n>\n> Yay, this hunk (and the one for mru.h) is satisfying.\n>\n>> @@ -40,7 +40,7 @@ static unsigned int pack_max_fds;\n>>  static size_t peak_pack_mapped;\n>>  static size_t pack_mapped;\n>>  struct packed_git *packed_git;\n>> -struct mru packed_git_mru = {{&packed_git_mru.list, &packed_git_mru.list}};\n>> +LIST_HEAD(packed_git_mru);\n>\n> Much nicer.\n>\n>> @@ -859,9 +859,18 @@ static void prepare_packed_git_mru(void)\n>>  {\n>>       struct packed_git *p;\n>>\n>> -     mru_clear(&packed_git_mru);\n>> -     for (p = packed_git; p; p = p->next)\n>> -             mru_append(&packed_git_mru, p);\n>> +     struct list_head *pos;\n>> +     struct list_head *tmp;\n>> +     list_for_each_safe(pos, tmp, &packed_git_mru)\n>> +             list_del_init(pos);\n>\n> This matches the original code, which did the clear/re-create, resetting\n> the mru to the \"original\" pack order. But I do wonder if that's actually\n> necessary. Could we skip that and just add any new packs to the list?\n\nBut if we do not clear the older entries from the list, wouldn't there be a\nproblem when you access packed_git_mru->next, since that will be populated\ninstead of being empty? Or am I misunderstanding something here?\n\n>\n> That goes hand-in-hand with the idea of dropping the \"next\" pointer that\n> I mentioned above.\n>\n>> +     INIT_LIST_HEAD(&packed_git_mru);\n>\n> I think this INIT_LIST_HEAD() isn't necessary anymore. In the original\n> code, we just freed each of the mru_entry structs, which meant we had to\n> forcibly reset the list head to be empty. But here you've used\n> list_del_init(), so after deleting everything, packed_git_mru should\n> already be empty.\n>\n>> +     for (p = packed_git; p; p = p->next) {\n>> +             struct packed_git *cur = xmalloc(sizeof(*packed_git));\n>> +             cur = p;\n>> +             list_add_tail(&cur->mru, &packed_git_mru);\n>> +     }\n>\n> This malloc can go away. The original mru code kept a separate entry,\n> but now we don't need that. So here you're just leaking it when you\n> assign \"cur = p\" (in fact, I think you can get rid of cur entirely).\n\nAh yes, I'll fix this.\n\n>\n>> @@ -1830,10 +1839,11 @@ int find_pack_entry(const unsigned char *sha1, struct pack_entry *e)\n>>       if (!packed_git)\n>>               return 0;\n>>\n>> -     list_for_each(pos, &packed_git_mru.list) {\n>> -             struct mru *p = list_entry(pos, struct mru, list);\n>> -             if (fill_pack_entry(sha1, e, p->item)) {\n>> -                     mru_mark(&packed_git_mru, p);\n>> +     list_for_each(pos, &packed_git_mru) {\n>> +             struct packed_git *p = list_entry(pos, struct packed_git, mru);\n>> +             if (fill_pack_entry(sha1, e, p)) {\n>> +                     list_del(&p->mru);\n>> +                     list_add(&p->mru, &packed_git_mru);\n>>                       return 1;\n>>               }\n>>       }\n>\n> And this hunk looks pretty good (though if we added a move-to-front\n> helper, it could be used here, too).\n\nThanks!\ngargi\n>\n> -Peff\n"},{"id":"332348","messageId":"20171112161617.fhysws3idztguu23@sigill.intra.peff.net","threadId":"47171","inReplyTo":"CAOCi2DGYQr4jFf5ObY2buyhNJeaAPQKF8tbojn2W0b18Eo+Wgw@mail.gmail.com","subject":"Re: [PATCH] mru: Replace mru.[ch] with list.h implementation","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-11-12T16:16:18Z","receivedAt":"2017-11-12T16:16:24Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Nov 12, 2017 at 12:49:17PM +0000, Gargi Sharma wrote:\n\n> > Sort of a side note, but seeing these two list pointers together makes\n> > me wonder what we should do with the list created by the \"next\" pointer.\n> > It seems like there are three options:\n> >\n> >   1. Convert it to \"struct list_head\", too, for consistency.\n> >\n> >   2. Leave it as-is. We never delete from the list nor do any fancy\n> >      manipulation, so it doesn't benefit from the reusable code.\n> >\n> >   3. I wonder if we could drop it entirely, and just keep a single list\n> >      of packs, ordered by mru. I'm not sure if anybody actually cares\n> >      about accessing them in the \"original\" order. That order is\n> >      reverse-chronological (by prepare_packed_git()), but I think that\n> >      was mostly out of a sense that recent packs would be accessed more\n> >      than older ones (but having a real mru strategy replaces that\n> >      anyway).\n> >\n> > What do you think?\n> I think in the long run, it'll be easier if there is only a single\n> list of packs given\n> that no one needs to access the list in order.\n\nYeah, it's that \"given...\" that makes me just a little nervous that I'm\nmissing something.\n\n> If we go down road 1/3, would it be better if I sent an entirely\n> different patch or\n> a patch series with patch 1 as removing mru[.ch] and patch 2 as removing\n> next pointer from the struct?\n\nI think you could do it as a 2-patch series like that, or you could send\nthe first patch now (since I think it stands on its own merits) and do\nthe other one later on top.\n\n> > This matches the original code, which did the clear/re-create, resetting\n> > the mru to the \"original\" pack order. But I do wonder if that's actually\n> > necessary. Could we skip that and just add any new packs to the list?\n> \n> But if we do not clear the older entries from the list, wouldn't there be a\n> problem when you access packed_git_mru->next, since that will be populated\n> instead of being empty? Or am I misunderstanding something here?\n\nWhat I mean is that instead of clearing and re-adding all of the packs\n(including any new ones we picked up by rescanning the directory), we\nwould _just_ add new ones to the list.\n\nSo I think we'd scrap this whole \"set up the mru\" preparation here and\njust teach install_packed_git() to add the new pack to the MRU list.\n\n-Peff\n"},{"id":"334677","messageId":"CAL21BmmF2=+UVnuVZprn0vKh+PP=wz3QpH_=AOfUsY9K0AfWzA@mail.gmail.com","threadId":"47171","inReplyTo":"20171112161617.fhysws3idztguu23@sigill.intra.peff.net","subject":"Re: [PATCH] mru: Replace mru.[ch] with list.h implementation","fromName":"Оля Тележная","fromEmail":"olyatelezhnaya@gmail.com","sentAt":"2017-12-12T14:07:46Z","receivedAt":"2017-12-12T14:08:29Z","isPatch":true,"sender":{"key":"olyatelezhnaya@gmail.com","avatar":"https://avatars.githubusercontent.com/u/11246099?v=4"},"body":"Gargi,\nIf you have some difficulties - please feel free to ask questions\n(here or you can write me directly). I will be happy to help you.\nAs I understand, you are super close to finish your first patch.\n\nOlga\n"}]}