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

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

[Zhang Yi]

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/

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

[Hariom verma]

Hi

On Tue, Mar 28, 2023 at 9:20 PM Zhang Yi <18994118902@163.com> wrote:
>
> 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.

> * 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.

> * 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

> 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

> * 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.

> * 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.

> * 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?

> * 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