[OUTREACHY V2] Unify ref-filter formats with other --pretty formats[proposal]

>
> ##Proposed Project
>
> Abstract
>
> Git has an old problem of duplicated implementations of some logic.
> For example, Git had at least 4 different implementations to format
> command output for different commands. The foremost aim of this
> project is to simplify codebase by getting rid of duplication of a
> similar logic and, as a result, simplify adding new functionality.
> The current task is to reuse ref-filter formatting logic to minimize
> code duplication and to have one unified interface to extract all
> needed data from the object and to print it properly.
>
> ##Previous Work
>
> JayDeep Das(GSoC) tried to “add a new atom ‘signature’”. However, I
> have not been able to find his complete work in the public box, it
> seems his work was not complete. According to
> <https://github.com/JDeepD/git-1/commit/85ddfa4b33f2b6f05524e648e7165c722188093e>
> which was suggested at the outreachy website, it looks like he did not
> complete writing the tests for the signature atom he was unifying.
> Maybe with the help of the mentors, I could plan to start from where
> he stopped from.

> Hariom finished most of the formatting options and
> this will help me build on his work.  His work looks smart and
> understandable thus adding on his work will be easy. And also his blog
> is very fabulous, it’s a shooting point for me to start understanding
> the codebase very well.

> ##Summary of remaining tasks by Hariom
>
> -Around 30% log related tests are failing
>
> -Teach pretty-lib.{c,h} to handle incorrect formatting option
>
> -Email/MBoxed commit format needs work
>
> ##Some useful mailing lists links from Hariom
>
> - https://public-inbox.org/git/pull.684.v4.git.1598046110.gitgitgadget@gmail.com/
>
> - https://public-inbox.org/git/pull.707.git.1597841551.gitgitgadget@gmail.com/
>
> - https://public-inbox.org/git/pull.707.git.1597841551.gitgitgadget@gmail.com/
>

> Olga<olyatelezhnaya@gmail.com> has done great work in “Unifying Git’s
> format languages” during Outreachy Round 15 and continued even after
> that [from 28-09-2017 to 04-04-2019]. Her work is mostly related to
> `cat-file` and `ref-filter`.
>
> She already did a pretty nice job in preparing ref-filter for more
> general usage of its formatting logic. It will give me the possibility
> to make the migration of pretty.c easier.

>
> Hi,
>
> On Thu, Oct 27, 2022 at 5:28 PM NSENGIYUMVA WILBERFORCE
> <nsengiyumvawilberforce@gmail.com> wrote:
> >
> > ##Proposed Project
> >
> > Abstract
> >
> > Git has an old problem of duplicated implementations of some logic.
> > For example, Git had at least 4 different implementations to format
> > command output for different commands. The foremost aim of this
> > project is to simplify codebase by getting rid of duplication of a
> > similar logic and, as a result, simplify adding new functionality.
> > The current task is to reuse ref-filter formatting logic to minimize
> > code duplication and to have one unified interface to extract all
> > needed data from the object and to print it properly.
> >
> > ##Previous Work
> >
> > JayDeep Das(GSoC) tried to “add a new atom ‘signature’”. However, I
> > have not been able to find his complete work in the public box, it
> > seems his work was not complete. According to
> > <https://github.com/JDeepD/git-1/commit/85ddfa4b33f2b6f05524e648e7165c722188093e>
> > which was suggested at the outreachy website, it looks like he did not
> > complete writing the tests for the signature atom he was unifying.
> > Maybe with the help of the mentors, I could plan to start from where
> > he stopped from.
>
> maybe s/stopped from/stopped/
>
> You can elaborate a bit more on Jaydeep's work.
> Like,
> - What tests are missing?
> - Any dificulties he faced during writing tests?
>
> Also, in my final report, I mentioned refactoring the signature logic
> according to Junio's comment
> (https://public-inbox.org/git/xmqqzh7jcqv7.fsf@gitster.c.googlers.com/).
> Does Jaydeep's patch respect Junio's comment? I think you can include
> a bit about this too,
>
> > Hariom Verma contributed(https://harry-hov.github.io/blogs/posts/the-final-report)
> > tremendously towards “Unifying Git’s format languages” during his 2020
> > GSoC internship.
>
> s/Unifying Git’s format languages/Unifying ref-filter formats with
> other --pretty formats/
> s/during his 2020 GSoC internship/during GSoC'20/
>
> > Hariom finished most of the formatting options and
> > this will help me build on his work.  His work looks smart and
> > understandable thus adding on his work will be easy. And also his blog
> > is very fabulous, it’s a shooting point for me to start understanding
> > the codebase very well.
>
> It looks more like praise to me. I'm glad you like my work and blogs.
> But I would like to see some details here.
> Like work is almost 2+ years old. What changed in pretty.* and
> ref-filter.* since then?
> Is my work still compatible with the latest changes?
>
> > Hariom mentions in his report that 30 % of the
> > log related tests are failing, he also mentions that the cause of
> > tests failure is because of the missing mailmap logic and mbox/email
> > commit format.
>
> Okay. But see if you can gather more details about failing tests and
> remaining work.
>
> > Hariom also says it does not handle unknown formatting
> > options.
>
> what do you mean by "it" here?
>
> > I plan to start with his advice about the cause of the
> > failure of these tests and then intuitively refactor them into
> > something cool.
>
> I didn’t get the line "intuitively refactor them into something cool".
>
> > ##Summary of remaining tasks by Hariom
> >
> > -Around 30% log related tests are failing
> >
> > -Teach pretty-lib.{c,h} to handle incorrect formatting option
> >
> > -Email/MBoxed commit format needs work
> >
> > ##Some useful mailing lists links from Hariom
> >
> > - https://public-inbox.org/git/pull.684.v4.git.1598046110.gitgitgadget@gmail.com/
> >
> > - https://public-inbox.org/git/pull.707.git.1597841551.gitgitgadget@gmail.com/
> >
> > - https://public-inbox.org/git/pull.707.git.1597841551.gitgitgadget@gmail.com/
> >
>
> Okay
>
> > Olga<olyatelezhnaya@gmail.com> has done great work in “Unifying Git’s
> > format languages” during Outreachy Round 15 and continued even after
> > that [from 28-09-2017 to 04-04-2019]. Her work is mostly related to
> > `cat-file` and `ref-filter`.
> >
> > She already did a pretty nice job in preparing ref-filter for more
> > general usage of its formatting logic. It will give me the possibility
> > to make the migration of pretty.c easier.
>
> ZheNing Hu continued the Olga's work during GSoC'21. You can tell a
> bit more about that too.
>
> --
>
> I would review the rest later.
>
> It seems like you used my proposal as a template. Just want to let you
> know, you are not restricted to using any particular template. Feel
> free to add or remove any section you find relevant.
>
> Thanks,
> Hariom

>
> Thanks Hariom for your comments.
>
> > I would review the rest later.
>
> Ok, thank you
>
> >  It seems like you used my proposal as a template
>
> I used your template.  Yeah in case there are things to add or remove,
> I will do so.
>
> Thank you so much for your comments, I am working on all of them. i
> hope by the end of today I will finish
>
>
> On Fri, Oct 28, 2022 at 11:05 AM Hariom verma <hariom18599@gmail.com> wrote:
> >
> > Hi,
> >
> > On Thu, Oct 27, 2022 at 5:28 PM NSENGIYUMVA WILBERFORCE
> > <nsengiyumvawilberforce@gmail.com> wrote:
> > >
> > > ##Proposed Project
> > >
> > > Abstract
> > >
> > > Git has an old problem of duplicated implementations of some logic.
> > > For example, Git had at least 4 different implementations to format
> > > command output for different commands. The foremost aim of this
> > > project is to simplify codebase by getting rid of duplication of a
> > > similar logic and, as a result, simplify adding new functionality.
> > > The current task is to reuse ref-filter formatting logic to minimize
> > > code duplication and to have one unified interface to extract all
> > > needed data from the object and to print it properly.
> > >
> > > ##Previous Work
> > >
> > > JayDeep Das(GSoC) tried to “add a new atom ‘signature’”. However, I
> > > have not been able to find his complete work in the public box, it
> > > seems his work was not complete. According to
> > > <https://github.com/JDeepD/git-1/commit/85ddfa4b33f2b6f05524e648e7165c722188093e>
> > > which was suggested at the outreachy website, it looks like he did not
> > > complete writing the tests for the signature atom he was unifying.
> > > Maybe with the help of the mentors, I could plan to start from where
> > > he stopped from.
> >
> > maybe s/stopped from/stopped/
> >
> > You can elaborate a bit more on Jaydeep's work.
> > Like,
> > - What tests are missing?
> > - Any dificulties he faced during writing tests?
> >
> > Also, in my final report, I mentioned refactoring the signature logic
> > according to Junio's comment
> > (https://public-inbox.org/git/xmqqzh7jcqv7.fsf@gitster.c.googlers.com/).
> > Does Jaydeep's patch respect Junio's comment? I think you can include
> > a bit about this too,
> >
> > > Hariom Verma contributed(https://harry-hov.github.io/blogs/posts/the-final-report)
> > > tremendously towards “Unifying Git’s format languages” during his 2020
> > > GSoC internship.
> >
> > s/Unifying Git’s format languages/Unifying ref-filter formats with
> > other --pretty formats/
> > s/during his 2020 GSoC internship/during GSoC'20/
> >
> > > Hariom finished most of the formatting options and
> > > this will help me build on his work.  His work looks smart and
> > > understandable thus adding on his work will be easy. And also his blog
> > > is very fabulous, it’s a shooting point for me to start understanding
> > > the codebase very well.
> >
> > It looks more like praise to me. I'm glad you like my work and blogs.
> > But I would like to see some details here.
> > Like work is almost 2+ years old. What changed in pretty.* and
> > ref-filter.* since then?
> > Is my work still compatible with the latest changes?
> >
> > > Hariom mentions in his report that 30 % of the
> > > log related tests are failing, he also mentions that the cause of
> > > tests failure is because of the missing mailmap logic and mbox/email
> > > commit format.
> >
> > Okay. But see if you can gather more details about failing tests and
> > remaining work.
> >
> > > Hariom also says it does not handle unknown formatting
> > > options.
> >
> > what do you mean by "it" here?
> >
> > > I plan to start with his advice about the cause of the
> > > failure of these tests and then intuitively refactor them into
> > > something cool.
> >
> > I didn’t get the line "intuitively refactor them into something cool".
> >
> > > ##Summary of remaining tasks by Hariom
> > >
> > > -Around 30% log related tests are failing
> > >
> > > -Teach pretty-lib.{c,h} to handle incorrect formatting option
> > >
> > > -Email/MBoxed commit format needs work
> > >
> > > ##Some useful mailing lists links from Hariom
> > >
> > > - https://public-inbox.org/git/pull.684.v4.git.1598046110.gitgitgadget@gmail.com/
> > >
> > > - https://public-inbox.org/git/pull.707.git.1597841551.gitgitgadget@gmail.com/
> > >
> > > - https://public-inbox.org/git/pull.707.git.1597841551.gitgitgadget@gmail.com/
> > >
> >
> > Okay
> >
> > > Olga<olyatelezhnaya@gmail.com> has done great work in “Unifying Git’s
> > > format languages” during Outreachy Round 15 and continued even after
> > > that [from 28-09-2017 to 04-04-2019]. Her work is mostly related to
> > > `cat-file` and `ref-filter`.
> > >
> > > She already did a pretty nice job in preparing ref-filter for more
> > > general usage of its formatting logic. It will give me the possibility
> > > to make the migration of pretty.c easier.
> >
> > ZheNing Hu continued the Olga's work during GSoC'21. You can tell a
> > bit more about that too.
> >
> > --
> >
> > I would review the rest later.
> >
> > It seems like you used my proposal as a template. Just want to let you
> > know, you are not restricted to using any particular template. Feel
> > free to add or remove any section you find relevant.
> >
> > Thanks,
> > Hariom

>> maybe s/stopped from/stopped/
>
> Can I know about how this format of writing works? I have similar
> comments in the previous proposal, but I do not understand how this
> works.

>
> Hi,
>
> > Olga<olyatelezhnaya@gmail.com> has done great work in “Unifying Git’s
> > format languages” during Outreachy Round 15 and continued even after
> > that [from 28-09-2017 to 04-04-2019]. Her work is mostly related to
> > `cat-file` and `ref-filter`.
> >
> > She already did a pretty nice job in preparing ref-filter for more
> > general usage of its formatting logic. It will give me the possibility
> > to make the migration of pretty.c easier.
>
> ZheNing Hu continued the Olga's work during GSoC'21. You can tell a
> bit more about that too.
>

> --
>
> I would review the rest later.
>
> It seems like you used my proposal as a template. Just want to let you
> know, you are not restricted to using any particular template. Feel
> free to add or remove any section you find relevant.
>
> Thanks,
> Hariom

> > > Olga<olyatelezhnaya@gmail.com> has done great work in “Unifying Git’s
> > > format languages” during Outreachy Round 15 and continued even after
> > > that [from 28-09-2017 to 04-04-2019]. Her work is mostly related to
> > > `cat-file` and `ref-filter`.
> > >
> > > She already did a pretty nice job in preparing ref-filter for more
> > > general usage of its formatting logic. It will give me the possibility
> > > to make the migration of pretty.c easier.
> >
> > ZheNing Hu continued the Olga's work during GSoC'21. You can tell a
> > bit more about that too.
>
> I'm afraid I'm skeptical about the progress of this project. Yes, this
> project has
> been going on for too long, probably 3 years, and it is long overdue
> to be merged
> into master. Maybe we all need to rethink the nature of this project instead of
> rushing to start writing code.
>
> As far as I know, these unified format refactor are easy to implement, but as we
> use more complex parsing logic, there will be a lot of performance degradation.
>
> I recommend new contributors to perform performance analysis and performance
> optimization directly based on the original developer's patches.