{"thread":{"id":"55567","subject":"The way to maintain lots of packfile-uris configs?","startedAt":"2021-04-27T03:02:34Z","lastAt":"2021-04-27T03:02:34Z","messageCount":1,"participants":["滕龙"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"423053","messageId":"CADMgQSR1rWW694tWq3aJgPuhcfYuxUA_L9vOdjNrWXHpypaqQQ@mail.gmail.com","threadId":"55567","inReplyTo":null,"subject":"The way to maintain lots of packfile-uris configs?","fromName":"滕龙","fromEmail":"dyroneteng@gmail.com","sentAt":"2021-04-27T03:02:19Z","receivedAt":"2021-04-27T03:02:34Z","isPatch":false,"sender":{"key":"dyroneteng@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7803958?v=4"},"body":"Recently I read about the implementation of packfile-uris feature, the\nserver realizes the mapping between blob and packfile-uri through\nmultiple configurations of <uploadpack.blobPackfileUri>.\n\nI have a question. If there are many such mappings, there will be a\nlot of <uploadpack.blobPackfileUri> in the warehouse. If I want to\nmaintain them (such as update and delete), it is not an easy task. I\nknow that there are still many works to be done on this feature in the\nfuture. Regarding the above point, I don't know how the community\nconsiders it and whether it will do some targeted optimization.\n\nOne of my methods is (maybe not very thoughtful), is it possible to\nsupport an extended method, such as packfile-uris-hook, through fork\nits child process, interact with pack-objects, packfile-uris-hook\ndefault implementation Is read from uploadpack.blobPackfileUri\nconfiguration.\n\nThis method may not be the best, but the focus of my expression is a\nscalable method that allows the user to flexibly decide how to\nmaintain packfile-uris.\n"}]}