{"thread":{"id":"59528","subject":"[GSOC] [PROPOSAL v3] Draft of proposal for \"Unify ref-filter formats with other pretty formats\"","startedAt":"2023-04-03T18:01:56Z","lastAt":"2023-04-10T08:10:50Z","messageCount":2,"participants":["Zhang Yi"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"474700","messageId":"17b1acf2.6231.18748391cab.Coremail.18994118902@163.com","threadId":"59528","inReplyTo":null,"subject":"[GSOC] [PROPOSAL v3] Draft of proposal for \"Unify ref-filter formats with other pretty formats\"","fromName":"Zhang Yi","fromEmail":"18994118902@163.com","sentAt":"2023-04-03T17:45:15Z","receivedAt":"2023-04-03T18:01:56Z","isPatch":false,"sender":{"key":"18994118902@163.com","avatar":"https://avatars.githubusercontent.com/u/48300302?v=4"},"body":"Thanks for Christian Couder's comments. I realize that I should have a deeper\nunderstanding of this project. So I have tried related commands and read related\ndocuments.\n\nImprovement vs v2:\n1. A re-designed plan.\n2. Put section \"Estimated Timeline\" next to \"Steps\".\n3. Add parts about works of Nsengiyumva Wilberforce.\n4. Fix some spell mistakes.\n\nThere seems no time left for a cycle of re-draft. Could I submit this proposal?\n\nThanks for all comments.\n\n* Unify ref-filter formats with other pretty formats\n\n* Personal Information\n\nFull name: Zhang Yi\n\nE-mail: 18994118902@163.com\nTel: (+86)18994118902\n\nEducation: Wuhan University of Technology (China)\nMajor: Computer engineering \nYear: First-year postgraduate student\n\nGithub: https://github.com/zhanyi22333\n\n*  Synopsis\n\n** Motivation\n\nGit has different implements to format command output, which makes chaos and\nhinder improvement of code quality.\n\nAim to unify the different implementations to format output for different\ncommands, we want to transform pretty into ref-filter formatting logic. According\nto the present situation, I may need to add more ref-filter atoms to replace\npretty. After all pretty atoms have corresponding atoms in ref-filter, we still\nneed to reuse ref-filter in pretty. To promise the backward compatibility, it is\nbetter to translate a pretty formatting string to a ref-filter formatting string,\nthen use ref-filter's functions to complete the formatting process.\n\n\n** Previous Work\n\n  - `git for-each-ref`, `git branch` and `git tag` formats into the\nref-filter formats:\n\ndone by Karthik Nayak (GSoC 2015)\n\n  -  `git cat-file` formats and the ref-filter formats:\n\nstarted by Olga Telezhnaya (Outreachy 2017-2018),\ncontinued by ZheNing Hu (GSoC 2021),\nbut still not finished due to tricky performance issues.\n\n  - ref-filter formats and pretty formats:\n\ntarted by Hariom Verma (GSoC 2020)\ncontinued a bit by Jaydeep Das. (GSoC 2022)\nNsengiyumva Wilberforce continued to work on this during the time of Outreachy\nand after Outreachy with persistence. His work on the \"signature\" atom\nshould be mostly over when the GSoC starts. (Outreachy 2022-2023)\n\nHere are links to their blogs or works.\n- Olga Telezhnaya: Here are Olga Telezhnaya's detailed and helpful blogs.[1]\n- ZheNing Hu: There are a lot of patches which are concluded in his final\nblog [2]\n- Hariom Verma: There are also a lot of patches which are concluded in his final\nblog [3]\n- Jaydeep Das: Patch: gpg-interface: add function for converting trust level to\nstring [4]\n- Nsengiyumva Wilberforce:Patch: ref-filter: add new atom \"signature\" atom [5]\n\n** What is left\n\nSince the work of \"signature\" atoms will be finished by Nsengiyumva Wilberforce,\nThere may be some other atoms left for ref-filter formats and pretty formats.\nAfter I checked the documents of pretty and ref-filter, I found that the '%w' in\npretty seems has no substitute in ref-filter. And the '%m' placeholder may also\nneed a substitute.\n\n** Steps\n\n1. Try best to understand related code. It is necessary to understand the way\nref-filter works. Since the work of adding signature atom by Nsengiyumva \nWilberforce is strongly related and latest, I think I should pay great attention.\nWhat's more, I may need to understand how align atom works because '%w' has a\nrange influence and it is better to have the power to control the scale of range\nwith the help of \"%end\".\n2. Add a file name which is a substitute for '%w'. The code should pass tests and\nhas related documents.\n3. Add a file name which is a substitute for '%m'. The code should pass tests and\nhas related documents.\n4. Recheck the correspondence between the atoms of pretty and ref-filter. There\nshould be none left.\n5.  Work on reusing ref-filter logic in pretty, which looks like a huge project.\nI need to have a good understanding on previous works about what should and\nshouldn't. It seems a bit earlier for me to think about it.\n(Hope I can get to this step)\n\n** Estimated Timeline\n\nThe official GSOC code time starts from 05-29 to 08-28, which is 13 weeks.\nThe period from 06-05 to 06~30 is near the end of the semester. There are many\nclasses for me. So I guess I may not be productive during this period.\nI think it is a bit time-limited if I follow the official timeline. It seems\nnecessary to do some work in advance.\n\n1. Preparatory work:\n Period:\n  04-01 ~ 05-28\n  About 8 weeks\n Tasks:\n   1. Trying to understand the formatting logic behind pretty and ref-filter.\n   2. Make some trial changes to help understanding.\n   3. Understand the work of Nsengiyumva Wilberforce.\n   4. Figure out the way align atom works.\n\n2. Add a new field name.\n Period:\n  05-29 ~ 07-07 (include inactive period)\n  Week 1~6\n  6 weeks\n Tasks:\n  Based on the preparatory work, write a new field name for 'w' placeholder in\n  pretty. It should pass tests and be well-documented.\n Deliverables:\n    A new field name for 'w' placeholder in pretty.\n    Test scripts.\n    Added documents.\n\n3. Active code period 1\n Period:\n  07-10 ~ 07-28\n  Week 7~9\n  3 weeks\n Tasks:\n  Work on a new filed name to replace 'm' placeholder. Also it need to pass\n  tests and be well-documented.\n Deliverables:\n    A new field name for 'm' placeholder in pretty.\n    Test scripts.\n    Added documents.\n\n4. Finishing touches\n Period:\n  07-31 ~ 08-26\n  Week 10~13\n  4 weeks\n Tasks:\n  If the previous estimate is over-optimistic, it is time for fault-tolerant.In\n  the best condition, I should finish the two new field names. After that, I will\n  recheck the correspondence between the atoms of pretty and ref-filter. If\n  all preparatory work is done, I will put effort on reusing ref-filter logic in\n  pretty.\n\n* Benefits to Community\n\nI'm willing to stay around after the project. By that time, I will be in my\nsecond year without classes. And my tutor has an open mind about my request to\ninvolve in an open source project by now. Considering the subjective and\nobjective conditions, I think there is a high possibility that I will stay\naround.\n\nParticularly, I wish to be a co-mentor if I have the ability. There may be some\ndifficulties. But what I learn from my finite experience is that you should not\nrefuse something positive just because of the difficulties in the mind. A\nfresh new job may be difficult, but it can show me the possibilities of the\nworld, which means changing my mind.\n\nWhat's more, I tried to persuade a schoolmate who I think is kind of obsessed\nwith technology to take part in an open source community for both self-growth and\ncompanion. And I failed, because he thinks it is hard.  It's always hard to\nchange Others' deep-rooted ideas by word. But I think the actions speak louder\nthan words. Maybe after the project, I can change the minds of people around me\nabout joining an open source community. There may be no visual benefits to the\nGit Community but should be beneficial to the whole open source community.\n\n* Microproject\n\nt9700: modernize test scripts [6]\n\nThe microproject patches have been merged. The merge info is as below:\n\ncommit 8760a2b3c63478e8766b7ff45d798bd1be47f52d\nMerge: a2d2b5229e 509d3f5103\nAuthor: Junio C Hamano <gitster@pobox.com>\nDate:   Tue Feb 28 16:38:47 2023 -0800\n\n    Merge branch 'zy/t9700-style'\n\n    Test style fixes.\n\n    * zy/t9700-style:\n      t9700: modernize test scripts\n\n\n\n* Grasp from related work\n\n** From Hariom Verma's blog\nWalking through the blogs of Hariom Verma, I find many things useful.\n\n*** Debugging\n\nAn extremely informative(step-by-step) debugging guide by Christian. [7]\n\n*** 11 questions for understanding someone's work. [8]\n\n1. What was the goal of each patch?\n2. which approach did she took to achieve the goal?\n3. what were the goals of the patch series?\n4. which approach did she took to achieve the goals?\n5. what was the goal of her previous patch series?\n6. what was the general direction her patch series were going?\n7. why did she took that direction?\n8. are there ways to continue in the same direction?\n9. are there ways to achieve similar goals?\n10. how were her goals similar and different from the goals in my proposal?\n11. is it possible to use the same approach?\n\n*** Else\n\nThere are many details about his work progress. I can refer to them when I am in\nsimilar situations.\n\n** From ZheNing Hu's blog\n\n*** Time analyzing\n\nUse performance testing tools to analyze the time-consuming steps of\n`git cat-file --batch`.\n\n Using Google's `gperftools`:\n1. Add the link parameter `-lprofiler` in `config.mak`: `CFLAGS += -lprofiler`.\n2. `make`.\n3. Use `CPUPROFILE=/tmp/prof.out /<path>/git cat-file --batch-check\n--batch-all-objects`\nto run the git and general `prof.out`, which contains the results of\nperformance analysis.\n4. Use `pprof --text /<path>/git /tmp/prof.out` to display the result\nin the terminal.\n\n*** About Github CI\n\n\"GitHub-Travis CI hints\" in Documentation/SubmittingPatches\n\n*** Else\n\nHe also writes his process of debugging and optimization in detail. It's worth\ndeepening into when I need them.\n\nThis proposal draft benefits from the works of predecessors much. Thanks.\n\n** From Olga Telezhnaia's blog\n\n1. There is potential emotional problems related to remote works.\n2. It may be a good idea to try different ways of communication.\n3. I should learn needed expertise. For example, I should learn more about shell\nscripts.\n4. The plan may change from time to time. But I should talk about it with mentors\nevery 2-3 weeks to focus on the final goal and middle steps.\n\n* Biograhical information\n\nIt is always funny to recall that I first learned about Linux in a stimulated\nhacker game in my fresh year in college. After that, I tried to teach myself\nLinux and started to know open source projects. Overcome many difficulties and I\nfinally know something shallow about Linux. As a side effect, I am more\nenthusiastic and better at programming compared with my schoolmates. But the\nperiod of stagnation came, I began to write some meaningless projects for school\ntasks and repeated myself without progress. The best out of the worst, I touched\nexcellent open source software during the time, such as vim, emacs, visual\nstudio code, Qt, VLC and, of course, git. Near the end of my junior year, I read\nan article about learning by contributing to an open source project by a geek\nin the community of emacs. Almost at the same time, I knew the GSOC and preferred\nto take part in git. But it was near the start date of my plan for postgraduate\nqualifying examination. So I just postponed the stuff for GSOC.  Luckily, I\npassed the examination. After I got used to life as a postgraduate student, I\nfelt the motivation to progress again. Then I tried to contribute for git. Now I\njust finished a micro project, which seems trivial. But it really let me have a\ndeeper understanding of open source and free software and more motivation to\ncontribute. I hope I can stay here a long time before being involved with other\ninteresting projects since the quality is more important than the quantity.\nI know it seems a bit stubborn to believe that contributing will lead to\nprogress, which is also influenced by my learning attitude. But without action,\nI can not verify the belief.  Sooat least I will try to contribute for one year.\nAfter that, I hope I can have a better understanding.\n\nSorry, the above text may be messing. In short, I will try to contribute for\ngit for at least one year.\n\n* Closing remarks\n\nIt seems blogs will help much for later work. I think It worth rebuilding my\nblog site on github.\n\nThanks for Christian Couder's and Hariom Verma's help.\n\n\n[1] https://medium.com/@olyatelezhnaya\n[2] https://public-inbox.org/git/CAOLTT8SxHuH2EbiSwQX6pyJJs5KyVuKx6ZOPxpzWLH+Tbz5F+A@mail.gmail.com/\n[3] https://harry-hov.github.io/blogs/posts/the-final-report\n[4] https://public-inbox.org/git/pull.1281.git.1657202265048.gitgitgadget@gmail.com/\n[5] https://public-inbox.org/git/pull.1452.git.1672102523902.gitgitgadget@gmail.com/#t\n[6] https://lore.kernel.org/git/20230222040745.1511205-1-18994118902@163.com/\n[7] https://public-inbox.org/git/CAP8UFD3Bd4Af1XZ00VyuHnQs=MFrdUufKeePO1tyedWoReRjwQ@mail.gmail.com/\n[8] https://harry-hov.github.io/blogs/posts/week1-the-ten-questions\n"},{"id":"475054","messageId":"17ee1b01.5434.1876a37a5ed.Coremail.18994118902@163.com","threadId":"59528","inReplyTo":"17b1acf2.6231.18748391cab.Coremail.18994118902@163.com","subject":"Re:[GSOC] [PROPOSAL v3] Draft of proposal for \"Unify ref-filter formats with other pretty formats\"","fromName":"Zhang Yi","fromEmail":"18994118902@163.com","sentAt":"2023-04-10T08:10:44Z","receivedAt":"2023-04-10T08:10:50Z","isPatch":false,"sender":{"key":"18994118902@163.com","avatar":"https://avatars.githubusercontent.com/u/48300302?v=4"},"body":"\n\nHi, I have done some preparatory work. I read most part of the patch\n\"ref-filter: add new \"signature\" atom\"[1] but the part of the test script is\nleft.\nI plan to read details about test scripts if the previous work of the patch is\nwell down.\n* My questions\n** Are there more aspects I need to focus when reading other's\npatches?\n** Are there other patches necessary to read?\n\n\nThanks for all suggestions.\nBelow is what I grasp from ref-filter: add new \"signature\" atom patches. I will\nput it on my blog site later.\n\n\n* v1\n** The goal of v1\nAdd \"signature\" atom with `grade`,`signer`, `key`, `fingerprint`,\n`primarykeyfingerprint`, `trustlevel` as arguments.\nTo get constitutes for %GG, %G?, %GS, %GK, %GF, %GP, and %GT pretty formats.\n** The approach\n*** enum\natom_type; ATOM_SIGNATURE: used as the index of valid_atom array.\n*** struct\nused_atom; struct {...} signature: add signature atom and its options.\nvalid_atom ; [ATOM_SIGNATURE]: seems build a map between \"signature\" and\nfunction \"signature_atom_parser\".\n*** function\n**** add\nstatic int signature_atom_parser: Set \"signature.option\" according to args.\nstatic void grab_signature: Set the result string in atom_value.value for\nsignature options. There are more details need to understand.\n**** modify\nstatic void grab_values: add grab_signature in case OBJ_COMMIT.\n*** document\n*** test scripts\n** Others' comments on v1\n*** Junio C Hamano\n1. Lack motivation.\n2. Need to deal with signed tag.\n3. Improve the style of \"if else\".\n4. Rename grab_signature to grab_commit_signature. This make easier for future\ndevelopers to understand and add \"grab_tag_signature\".\n5. Add space between cast and value.\n6. Check used-atom to make sure there is need to do signature processing.\n7. A call to check_commit_signature() should have a matching call to\nsignature_check_clear().\n*** Jeff King\n1. Add an annotation for the unused parameter, which is necessary when\n-Wunused-parameter is on.\n2. In signature_atom_parser, return err_bad_arg for wrong arg. This make the\nerror message match the others.\n* v2 seems meet some mistake about message ID\n1. More detailed commit message.\n2. Add parse_signature_option(), which return value for struct signature.option\nor -1 when get wrong arg. This function is used in grab_signature() and\nsignature_atom_parser().\n3. Modify signature_atom_parser(). Use parse_signature_option() to get opt and\nreturn err_bad_arg for wrong arg.\n4. Modify grab_signature(). Use parse_signature_option() to check name in\nused_atom and use check_commit_signature() with signature_check_clear() only\nonce.\n5. Add test for bare signature atom(%(signature)).\n* v3 and v4\n1. Remove test for bare signature atom because the result of the test is not\nsame on different platform.\n** Junio C Hamano's comments\nAvoid calling check_commit_signature() when no %(signature) atoms is used.\n* v5\n1. Add a signature_checked flag to avoid calling check_commit_signature()\nunnecessarily.\n2. Fix the test for bare signature atom(%(signature)) about trustdb.\n** Junio C Hamano's comments\nA question about differences between versions of GPG. It seems no relationship\nwith my work.\n* View these patches a whole\n** The general direction\n1. Register a new signature and its options in enum atom_type and struct used\natom.\n2. Define a foo_atom_parser() to convert string arg to int option.\n3. Bind atom with its foo_atom_parser() in valid_atom.\n4. Define a grab_foo() to set string s in struct atom_value according to option.\n5. Insert the grab_foo() into grab_values() function.\n** ls it possible to use the similar approach\nYes. I can follow the general idea of this patch. Of course, I need to finetune\nthe details according to the atom I work on.\n* Else\ncheck_commit_signature() is defined in commit.c.\nWhat is GPG?\nhttps://gnupg.org/\nGnuPG allows you to encrypt and sign your data and communications.\n\n\n[1] https://public-inbox.org/git/pull.1452.git.1672102523902.gitgitgadget@gmail.com/ \n\n"}]}