{"thread":{"id":"55857","subject":"[GSoC] Git Blog 3","startedAt":"2021-06-06T15:21:40Z","lastAt":"2021-06-07T12:05:12Z","messageCount":3,"participants":["ZheNing Hu","Christian Couder"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"426535","messageId":"CAOLTT8SJkVeSQKB7eN5Lw+OepeRXiZXWf_t-E09KxT1pmYBMag@mail.gmail.com","threadId":"55857","inReplyTo":null,"subject":"[GSoC] Git Blog 3","fromName":"ZheNing Hu","fromEmail":"adlternative@gmail.com","sentAt":"2021-06-06T15:21:06Z","receivedAt":"2021-06-06T15:21:40Z","isPatch":false,"sender":{"key":"adlternative@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58138461?v=4"},"body":"My third week blog finished:\nThe web version is here:\nhttps://adlternative.github.io/GSOC-Git-Blog-3/\n\n-----\n\n## Week3: Meticulousness is very important\n\n### What happened this week\n- I found a `git cat-file` bug this week, see:\n\n```bash\ngit cat-file --batch=batman --batch-all-objects\nbatman\nfatal: object 00345b5fe0aa8f45e9d1289ceb299f0489ea3fe1 changed type!?\n```\n\nIt seems that Git died for a strange reason: the type of\nan object changed? Is my Git object damaged? (Just like\na friend of mine, use `find . -type f -print0 | xargs -0 sed\n-i \"s/\\r//g\"` remove all the '\\r' of all files in a Git repository,\nthis caused most of his Git commands to fail.) So I tested\nit under different linux platforms, they all have this same\ndamage.\n\nAfter a series of testing and debugging, I found that\n`oid_object_info_extended()` did not get the type of\nobject.\n\nSo I submitted the patch for fix this bug to the Git mailing list in\n[[PATCH] [GSOC] cat-file: fix --batch report changed-type\nbug](https://lore.kernel.org/git/pull.965.git.1622363366722.gitgitgadget@gmail.com/),\nPeff tell us the essential reason for this bug:\n\nIn `845de33a5b (cat-file: avoid noop calls to\nsha1_object_info_extended, 2016-05-18)`, this patches\nskips the call to `oid_object_info_extended()` entirely when\n`--batch-all-objects` is in use, and the custom format does\nnot include any placeholders that require calling it. The correct\nsolution is to put checking if `object_info` is empty after\nsetting `object_info.typep`.\n\nFinally, thanks to the help of Jeff, I summit final patch in\n[[PATCH v2 1/2] [GSOC] cat-file: handle trivial --batch format with\n--batch-all-objects](https://lore.kernel.org/git/4af3b958dd056e2162fdc5d7f6600bcedde210b8.1622737766.git.gitgitgadget@gmail.com/).\n\nTalk of experience as a story: Even experienced programmers\nmake small mistakes, writing any code requires very careful thinking.\n- The checkpoints for rejecting `%(raw)` and `--<lang>` are incorrect.\nAt Junio’s reminder, I changed the checkpoint from\n`parse_ref_filter_atom()` to `verify_ref_format()`. My mentor Christian\npointed out some grammatical errors in the cover letter.\n- At the suggestion of Junio, I rebased `0efed94 ([GSOC]\nref-filter: add %(raw) atom)` on `1197f1a (ref-filter: introduce\nenum atom_type)`, they have a clash, after resolving the conflict,\nit's better for me to consider the code I implemented before and\nthe code I wrote now at the same time, I can find more problems\nand find better solutions.\n- I submitted the patch about `%(rest)`, `%(raw:textconv)` and\n`%(raw:filters)` for `ref-filter`, they are used to simulate some\nfunctions of `git cat-file`, my mentor Hariom noticed one of the\nformatting issues, I am waiting for more reviews for the time being.\n\n### What's the next step\n\nAs long as new atoms `%(rest)`, `%(raw:textconv)` and `%(raw:filters)`\nfor `ref-filter` can be accepted by Git, We can start to let `cat-file` use\n`ref-filter` logic on a large scale! Exciting! But the performance of\n`ref-filter`\nis still not good. Perhaps I need to find a new breakthrough in the\nperformance bottleneck of `ref-filter`.\n\nThanks!\n--\nZheNing Hu\n"},{"id":"426556","messageId":"CAP8UFD0WpfvWpGiQE9yizyzKL+HTie4KJHwWAzijT8N5RL1A=Q@mail.gmail.com","threadId":"55857","inReplyTo":"CAOLTT8SJkVeSQKB7eN5Lw+OepeRXiZXWf_t-E09KxT1pmYBMag@mail.gmail.com","subject":"Re: [GSoC] Git Blog 3","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2021-06-07T04:45:16Z","receivedAt":"2021-06-07T04:45:41Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Sun, Jun 6, 2021 at 5:21 PM ZheNing Hu <adlternative@gmail.com> wrote:\n>\n> My third week blog finished:\n> The web version is here:\n> https://adlternative.github.io/GSOC-Git-Blog-3/\n\nThanks!\n\n> -----\n>\n> ## Week3: Meticulousness is very important\n>\n> ### What happened this week\n> - I found a `git cat-file` bug this week, see:\n>\n> ```bash\n> git cat-file --batch=batman --batch-all-objects\n> batman\n> fatal: object 00345b5fe0aa8f45e9d1289ceb299f0489ea3fe1 changed type!?\n> ```\n>\n> It seems that Git died for a strange reason: the type of\n> an object changed? Is my Git object damaged? (Just like\n> a friend of mine, use `find . -type f -print0 | xargs -0 sed\n\nMaybe: s/, use/ used/\nor: s/, use/, who used/\n\n> -i \"s/\\r//g\"` remove all the '\\r' of all files in a Git repository,\n\ns/remove/to remove/\n\n> this caused most of his Git commands to fail.) So I tested\n> it under different linux platforms, they all have this same\n\ns/linux/Linux/\n\n> damage.\n\nMaybe: s/damage/breakage/\n\n>\n> After a series of testing and debugging, I found that\n> `oid_object_info_extended()` did not get the type of\n> object.\n>\n> So I submitted the patch for fix this bug to the Git mailing list in\n> [[PATCH] [GSOC] cat-file: fix --batch report changed-type\n> bug](https://lore.kernel.org/git/pull.965.git.1622363366722.gitgitgadget@gmail.com/),\n> Peff tell us the essential reason for this bug:\n\nMaybe: s/tell/told/\n\n>\n> In `845de33a5b (cat-file: avoid noop calls to\n> sha1_object_info_extended, 2016-05-18)`, this patches\n\ns/patches/patch/\n\n> skips the call to `oid_object_info_extended()` entirely when\n> `--batch-all-objects` is in use, and the custom format does\n> not include any placeholders that require calling it. The correct\n> solution is to put checking if `object_info` is empty after\n\ns/put checking/check/\n\n> setting `object_info.typep`.\n>\n> Finally, thanks to the help of Jeff, I summit final patch in\n\ns/summit/submitted a/\n\n> [[PATCH v2 1/2] [GSOC] cat-file: handle trivial --batch format with\n> --batch-all-objects](https://lore.kernel.org/git/4af3b958dd056e2162fdc5d7f6600bcedde210b8.1622737766.git.gitgitgadget@gmail.com/).\n>\n> Talk of experience as a story: Even experienced programmers\n> make small mistakes, writing any code requires very careful thinking.\n> - The checkpoints for rejecting `%(raw)` and `--<lang>` are incorrect.\n> At Junio’s reminder, I changed the checkpoint from\n> `parse_ref_filter_atom()` to `verify_ref_format()`. My mentor Christian\n> pointed out some grammatical errors in the cover letter.\n> - At the suggestion of Junio, I rebased `0efed94 ([GSOC]\n> ref-filter: add %(raw) atom)` on `1197f1a (ref-filter: introduce\n> enum atom_type)`, they have a clash, after resolving the conflict,\n\nMaybe: s/have/had/ and s/clash, after/clash. After/\n\nor: s/they have a clash, after/they clashed. After/\n\n> it's better for me to consider the code I implemented before and\n> the code I wrote now at the same time, I can find more problems\n> and find better solutions.\n> - I submitted the patch about `%(rest)`, `%(raw:textconv)` and\n> `%(raw:filters)` for `ref-filter`, they are used to simulate some\n\ns/, they/. They/\n\n> functions of `git cat-file`, my mentor Hariom noticed one of the\n\ns/, my/. My/\n\n> formatting issues, I am waiting for more reviews for the time being.\n>\n> ### What's the next step\n>\n> As long as new atoms `%(rest)`, `%(raw:textconv)` and `%(raw:filters)`\n\nMaybe: s/long/soon/\n\n> for `ref-filter` can be accepted by Git, We can start to let `cat-file` use\n\ns/, We/, we/\n\n> `ref-filter` logic on a large scale! Exciting! But the performance of\n> `ref-filter`\n> is still not good. Perhaps I need to find a new breakthrough in the\n> performance bottleneck of `ref-filter`.\n\nGreat, thanks!\n"},{"id":"426581","messageId":"CAOLTT8QTq1izxs3oE=TnwTR=W=+nGixpcEvktRRo8YdiEa=FTA@mail.gmail.com","threadId":"55857","inReplyTo":"CAP8UFD0WpfvWpGiQE9yizyzKL+HTie4KJHwWAzijT8N5RL1A=Q@mail.gmail.com","subject":"Re: [GSoC] Git Blog 3","fromName":"ZheNing Hu","fromEmail":"adlternative@gmail.com","sentAt":"2021-06-07T12:03:46Z","receivedAt":"2021-06-07T12:05:12Z","isPatch":false,"sender":{"key":"adlternative@gmail.com","avatar":"https://avatars.githubusercontent.com/u/58138461?v=4"},"body":"Christian Couder <christian.couder@gmail.com> 于2021年6月7日周一 下午12:45写道：\n>\n> On Sun, Jun 6, 2021 at 5:21 PM ZheNing Hu <adlternative@gmail.com> wrote:\n> >\n> > My third week blog finished:\n> > The web version is here:\n> > https://adlternative.github.io/GSOC-Git-Blog-3/\n>\n> Thanks!\n>\n> > -----\n> >\n> > ## Week3: Meticulousness is very important\n> >\n> > ### What happened this week\n> > - I found a `git cat-file` bug this week, see:\n> >\n> > ```bash\n> > git cat-file --batch=batman --batch-all-objects\n> > batman\n> > fatal: object 00345b5fe0aa8f45e9d1289ceb299f0489ea3fe1 changed type!?\n> > ```\n> >\n> > It seems that Git died for a strange reason: the type of\n> > an object changed? Is my Git object damaged? (Just like\n> > a friend of mine, use `find . -type f -print0 | xargs -0 sed\n>\n> Maybe: s/, use/ used/\n> or: s/, use/, who used/\n>\n> > -i \"s/\\r//g\"` remove all the '\\r' of all files in a Git repository,\n>\n> s/remove/to remove/\n>\n> > this caused most of his Git commands to fail.) So I tested\n> > it under different linux platforms, they all have this same\n>\n> s/linux/Linux/\n>\n> > damage.\n>\n> Maybe: s/damage/breakage/\n>\n> >\n> > After a series of testing and debugging, I found that\n> > `oid_object_info_extended()` did not get the type of\n> > object.\n> >\n> > So I submitted the patch for fix this bug to the Git mailing list in\n> > [[PATCH] [GSOC] cat-file: fix --batch report changed-type\n> > bug](https://lore.kernel.org/git/pull.965.git.1622363366722.gitgitgadget@gmail.com/),\n> > Peff tell us the essential reason for this bug:\n>\n> Maybe: s/tell/told/\n>\n> >\n> > In `845de33a5b (cat-file: avoid noop calls to\n> > sha1_object_info_extended, 2016-05-18)`, this patches\n>\n> s/patches/patch/\n>\n> > skips the call to `oid_object_info_extended()` entirely when\n> > `--batch-all-objects` is in use, and the custom format does\n> > not include any placeholders that require calling it. The correct\n> > solution is to put checking if `object_info` is empty after\n>\n> s/put checking/check/\n>\n> > setting `object_info.typep`.\n> >\n> > Finally, thanks to the help of Jeff, I summit final patch in\n>\n> s/summit/submitted a/\n>\n> > [[PATCH v2 1/2] [GSOC] cat-file: handle trivial --batch format with\n> > --batch-all-objects](https://lore.kernel.org/git/4af3b958dd056e2162fdc5d7f6600bcedde210b8.1622737766.git.gitgitgadget@gmail.com/).\n> >\n> > Talk of experience as a story: Even experienced programmers\n> > make small mistakes, writing any code requires very careful thinking.\n> > - The checkpoints for rejecting `%(raw)` and `--<lang>` are incorrect.\n> > At Junio’s reminder, I changed the checkpoint from\n> > `parse_ref_filter_atom()` to `verify_ref_format()`. My mentor Christian\n> > pointed out some grammatical errors in the cover letter.\n> > - At the suggestion of Junio, I rebased `0efed94 ([GSOC]\n> > ref-filter: add %(raw) atom)` on `1197f1a (ref-filter: introduce\n> > enum atom_type)`, they have a clash, after resolving the conflict,\n>\n> Maybe: s/have/had/ and s/clash, after/clash. After/\n>\n> or: s/they have a clash, after/they clashed. After/\n>\n> > it's better for me to consider the code I implemented before and\n> > the code I wrote now at the same time, I can find more problems\n> > and find better solutions.\n> > - I submitted the patch about `%(rest)`, `%(raw:textconv)` and\n> > `%(raw:filters)` for `ref-filter`, they are used to simulate some\n>\n> s/, they/. They/\n>\n> > functions of `git cat-file`, my mentor Hariom noticed one of the\n>\n> s/, my/. My/\n>\n> > formatting issues, I am waiting for more reviews for the time being.\n> >\n> > ### What's the next step\n> >\n> > As long as new atoms `%(rest)`, `%(raw:textconv)` and `%(raw:filters)`\n>\n> Maybe: s/long/soon/\n>\n> > for `ref-filter` can be accepted by Git, We can start to let `cat-file` use\n>\n> s/, We/, we/\n>\n> > `ref-filter` logic on a large scale! Exciting! But the performance of\n> > `ref-filter`\n> > is still not good. Perhaps I need to find a new breakthrough in the\n> > performance bottleneck of `ref-filter`.\n>\n> Great, thanks!\n\nWell, there are many typos in this blog... I will correct them in time.\n\nThanks.\n--\nZheNing Hu\n"}]}