threads / discuss / 59488

[GSOC] [PROPOSAL v1] Draft of proposal for "Unify ref-filter formats with other pretty formats"

Subject: [GSOC] [PROPOSAL v1] Draft of proposal for "Unify ref-filter formats with other pretty formats"

## tl;dr

2 messages between Mar 28, 2023 and Mar 29, 2023.

replies: 1people: 2as markdown or json

Zhang Yi· Mar 28, 2023, 15:50 UTC · lore

Hi, there is a my first versoin of proposal for "Unify ref-filter formats with other pretty formats". There may be many backwards. I'm ready for the correction.

Thanks for your attention.
* Unify ref-filter formats with other pretty formats
* Personal Information
Full name: Zhang Yi
E-mail: 18994118902@163.com
Tel: (+86)18994118902
Education: Wuhan University of Technology (China)
Major: Computer engineering 
Year: First-year postgraduate student
Github: https://github.com/zhanyi22333
* Synopsis

Git has at least four implements to format command output, which makes chaos and hinder improvement of code quality.

Aim to unify the different implementations to format output for different commands, we want to transform pretty into ref-filter formatting logic. According In the present situation, I need to add more ref-filter atoms to replace pretty.

In my mind, there are 6 steps logically:
1. Check and find a pretty atom which has no substitute in ref-filter.
2. Add reasonable test scripts and maybe documents in advance.
3. Build a ref-filter atom and its arguments to replace a pretty atom.
4. Make a translation between pretty formats and ref-filter arguments.
5. Modify the pretty code to ref-filter logic.
6. Recheck documents and run test scripts.
* Benefits to Community

I'm willing to stay around after the project. By that time, I will be in my second year without classes. And my tutor has an open mind about my request to invovle in an open source project by now. Consider the subjective and objective conditions, I think there is a high possibility that I will stay around.

Particularly, I wish to be a co-mentor if I have the ability. There may be some difficulties. But what I learn from my finite experience is that you should not refuse something positive just because of the difficulties in the mind. The fresh new job may be difficult, but it can show me the possibilities of the world, which means change my mind.

What's more, I tried to persuade a schoolmate who I think is kind of obsessed with technology to take part in an open source community for both self-growth and companion. And I failed, because he thinks it is hard. It's always hard to change Others' deep-rooted ideas by word. But I think the actions speak louder than words. Maybe after the project, I can change the minds of people around me about joining an open source community. There may be no visual benefits to the community of git but should be beneficial to the whole open source community.

* Microproject
t9700: modernize test scripts [1]
The microproject patches have been merged. The merge info is as below:
commit 8760a2b3c63478e8766b7ff45d798bd1be47f52d
Merge: a2d2b5229e 509d3f5103
Author: Junio C Hamano <gitster@pobox.com>
Date:   Tue Feb 28 16:38:47 2023 -0800
    Merge branch 'zy/t9700-style'
    Test style fixes.
    * zy/t9700-style:
      t9700: modernize test scripts
* Plan
** Deliverables
1. Documents.
2. Test scripts.
3. Modified ref-filter.
   3.1.  New atom and arguments
   3.2. New functions like foo_atom_parser, grab_foo
   3.3. modified functions like grab_values and static struct.
4. Modified pretty which is plugged in by ref-filter.
** Timeline and feasibility

It seems impossible for me to estimate the time consumed. The idea page [2] shows the expected time is between 175 hours and 350 hours. So I checked the timeline of GSOC, It shows that the official code time starts from 05-29 to 08-28 and can be extended to 11-06. After that I check my class schedule. The conclusion is as below:

1. now~06-05: around 2~3 classes every week. It is easy to cover the time
project needs.
2. 06-05~06-30: There are many classes on workdays. Hope I can take classes with
flexibility.
3.  After 06-30: This semester is finished.

I think it is a bit time-limited if I follow the official timeline. It seems necessary to do some work in advance.

* Related work
The blog by Hariom Verma shows the outline of the work.[3]

This proposal draft benefits from Nsengiyumva Wilberforce’s recent work [4] much. Thanks.

* Biograhical information

It is always funny to recall that I first learned about Linux in a stimulated hacker game in my fresh year in college. After that, I tried to teach myself Linux and started to know open source projects. Overcome many difficulties and I finally know something shallow about Linux. As a side effect, I am more enthusiastic and better at programming compared with my schoolmates. But the period of stagnation came, I began to write some meaningless projects for school tasks and repeated myself without progress. The best out of the worst, I touched excellent open source software during the time, such as vim, emacs, visual studio code, Qt, VLC and, of course, git. Near the end of my junior year, I read an article about learning by contributing to an open source project by a geek in the community of emacs. Almost at the same time, I knew the GSOC and preferred to take part in git. But it was near the start date of my plan for postgraduate qualifying examination. So I just postponed the stuff for GSOC. Luckily, I passed the examination. After I got used to life as a postgraduate student, I felt the motivation to progress again. Then I tried to contribute for git. Now I just finish a micro project, which seems trivial. But it really let me have a deeper understanding of open source and free software and more motivation to contribute. I hope I can stay a long time here before being involved with other interesting projects since the quality is more important than the quantity. I know it seems a bit stubborn to believe that contributing will lead to progress, which is also influenced by my learning attitude. But without action, I can not verify the belief. Sooat least I will try to contribute for one year. After that, I hope I can have a better understanding.

Sorry, the above text may be messing. In short, I will try to contribute for git for at least one year.

* Closing remarks
Thanks for Christian Couder's help.

[1] https://lore.kernel.org/git/20230222040745.1511205-1-18994118902@163.com/ [2] https://git.github.io/SoC-2023-Ideas/ [3] https://harry-hov.github.io/blogs/posts/the-final-report [4] https://lore.kernel.org/git/pull.1452.git.1672102523902.gitgitgadget@gmail.com/

Hariom verma· Mar 29, 2023, 12:23 UTC · re: Zhang Yi · lore

Re: [GSOC] [PROPOSAL v1] Draft of proposal for "Unify ref-filter formats with other pretty formats"

Hi
On Tue, Mar 28, 2023 at 9:20 PM Zhang Yi <18994118902@163.com> wrote:
Show 20 quoted lines
>
> Hi, there is a my first versoin of proposal for "Unify ref-filter formats with other
> pretty formats". There may be many backwards. I'm ready for the correction.
>
> Thanks for your attention.
>
> * Unify ref-filter formats with other pretty formats
>
> * Personal Information
>
> Full name: Zhang Yi
>
> E-mail: 18994118902@163.com
> Tel: (+86)18994118902
>
> Education: Wuhan University of Technology (China)
> Major: Computer engineering
> Year: First-year postgraduate student
>
> Github: https://github.com/zhanyi22333
Okay.
Show 17 quoted lines
> * Synopsis
>
> Git has at least four implements to format command output, which makes chaos and
> hinder improvement of code quality.
>
> Aim to unify the different implementations to format output for different
> commands, we want to transform pretty into ref-filter formatting logic. According
> In the present situation, I need to add more ref-filter atoms to replace
> pretty.
>
> In my mind, there are 6 steps logically:
> 1. Check and find a pretty atom which has no substitute in ref-filter.
> 2. Add reasonable test scripts and maybe documents in advance.
> 3. Build a ref-filter atom and its arguments to replace a pretty atom.
> 4. Make a translation between pretty formats and ref-filter arguments.
> 5. Modify the pretty code to ref-filter logic.
> 6. Recheck documents and run test scripts.

I would like to see more details here. Maybe you can explain every step you mentioned in detail. You can also include how much work has been done and what's left.

Show 6 quoted lines
> * Benefits to Community
>
> I'm willing to stay around after the project. By that time, I will be in my
> second year without classes. And my tutor has an open mind about my request to
> invovle in an open source project by now. Consider the subjective and objective
> conditions, I think there is a high possibility that I will stay around.

s/invovle/involve s/Consider/Considering

Show 13 quoted lines
> Particularly, I wish to be a co-mentor if I have the ability. There may be some
> difficulties. But what I learn from my finite experience is that you should not
> refuse something positive just because of the difficulties in the mind. The
> fresh new job may be difficult, but it can show me the possibilities of the
> world, which means change my mind.
>
> What's more, I tried to persuade a schoolmate who I think is kind of obsessed
> with technology to take part in an open source community for both self-growth and
> companion. And I failed, because he thinks it is hard.  It's always hard to
> change Others' deep-rooted ideas by word. But I think the actions speak louder
> than words. Maybe after the project, I can change the minds of people around me
> about joining an open source community. There may be no visual benefits to the
> community of git but should be beneficial to the whole open source community.
s/community of git/Git Community
Show 17 quoted lines
> * Microproject
>
> t9700: modernize test scripts [1]
>
> The microproject patches have been merged. The merge info is as below:
>
> commit 8760a2b3c63478e8766b7ff45d798bd1be47f52d
> Merge: a2d2b5229e 509d3f5103
> Author: Junio C Hamano <gitster@pobox.com>
> Date:   Tue Feb 28 16:38:47 2023 -0800
>
>     Merge branch 'zy/t9700-style'
>
>     Test style fixes.
>
>     * zy/t9700-style:
>       t9700: modernize test scripts
Great.
Show 28 quoted lines
> * Plan
>
> ** Deliverables
>
> 1. Documents.
> 2. Test scripts.
> 3. Modified ref-filter.
>    3.1.  New atom and arguments
>    3.2. New functions like foo_atom_parser, grab_foo
>    3.3. modified functions like grab_values and static struct.
> 4. Modified pretty which is plugged in by ref-filter.
>
> ** Timeline and feasibility
>
> It seems impossible for me to estimate the time consumed. The idea page [2]
> shows the expected time is between 175 hours and 350 hours. So I checked the
> timeline of GSOC, It shows that the official code time starts from 05-29 to
> 08-28 and can be extended to 11-06. After that I check my class schedule.
> The conclusion is as below:
>
> 1. now~06-05: around 2~3 classes every week. It is easy to cover the time
> project needs.
> 2. 06-05~06-30: There are many classes on workdays. Hope I can take classes with
> flexibility.
> 3.  After 06-30: This semester is finished.
>
> I think it is a bit time-limited if I follow the official timeline. It seems
> necessary to do some work in advance.

Can you merge "Deliverables" and "Timeline"? Please make a detailed timeline. It can be weekly or monthly depending on you.

Show 6 quoted lines
> * Related work
>
> The blog by Hariom Verma shows the outline of the work.[3]
>
> This proposal draft benefits from Nsengiyumva Wilberforce’s recent work [4]
> much. Thanks.

Maybe it's a good idea to include what you grasped from related work. A brief synopsis?

Show 37 quoted lines
> * Biograhical information
>
> It is always funny to recall that I first learned about Linux in a stimulated
> hacker game in my fresh year in college. After that, I tried to teach myself
> Linux and started to know open source projects. Overcome many difficulties and I
> finally know something shallow about Linux. As a side effect, I am more
> enthusiastic and better at programming compared with my schoolmates. But the
> period of stagnation came, I began to write some meaningless projects for school
> tasks and repeated myself without progress. The best out of the worst, I touched
> excellent open source software during the time, such as vim, emacs, visual
> studio code, Qt, VLC and, of course, git. Near the end of my junior year, I read
> an article about learning by contributing to an open source project by a geek
> in the community of emacs. Almost at the same time, I knew the GSOC and preferred
> to take part in git. But it was near the start date of my plan for postgraduate
> qualifying examination. So I just postponed the stuff for GSOC.  Luckily, I
> passed the examination. After I got used to life as a postgraduate student, I
> felt the motivation to progress again. Then I tried to contribute for git. Now I
> just finish a micro project, which seems trivial. But it really let me have a
> deeper understanding of open source and free software and more motivation to
> contribute. I hope I can stay a long time here before being involved with other
> interesting projects since the quality is more important than the quantity.
> I know it seems a bit stubborn to believe that contributing will lead to
> progress, which is also influenced by my learning attitude. But without action,
> I can not verify the belief.  Sooat least I will try to contribute for one year.
> After that, I hope I can have a better understanding.
>
> Sorry, the above text may be messing. In short, I will try to contribute for
> git for at least one year.
>
> * Closing remarks
>
> Thanks for Christian Couder's help.
>
> [1] https://lore.kernel.org/git/20230222040745.1511205-1-18994118902@163.com/
> [2] https://git.github.io/SoC-2023-Ideas/
> [3] https://harry-hov.github.io/blogs/posts/the-final-report
> [4] https://lore.kernel.org/git/pull.1452.git.1672102523902.gitgitgadget@gmail.com/
Thank you for your proposal. I left a few comments.

Regards, Hariom

← back to recent threads