* [GSoC] Unify ref-filter formats with other --pretty formats @ 2019-03-25 19:26 Kapil Jain 2019-03-25 21:17 ` Olga Telezhnaya 0 siblings, 1 reply; 9+ messages in thread From: Kapil Jain @ 2019-03-25 19:26 UTC (permalink / raw) To: git, Thomas Gummerer, Christian Couder, olyatelezhnaya Hi, Below are some two queries concerning https://git.github.io/SoC-2019-Ideas/#unify-ref-filter-formats-with-other---pretty-formats Q1) In pretty.h & pretty.c: void get_commit_format(const char *arg, struct rev_info *); This function Parses given arguments from "arg", checks it for correctness and * fill struct rev_info. In ref-filter.h & ref-filter.c: int verify_ref_format(struct ref_format *format); This function is Used to verify if the given format is correct and to parse out the used atoms. Now, the verify_ref_format function can be used inside get_commit_format function, hence reusing logic. Is this a correct example to work on, for this project ? If not, please point out an example so as to understand the problem statement better. Other than this I can't find any other example, for this project in pretty.* and ref-filter.* Perhaps some examples could be found in command specific files, right ? Q2) About a recurring term 'atom' in ref-filter and pretty: what is atom ? is it a piece of a whole document ? and what is meant by used atoms ? Thanks. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GSoC] Unify ref-filter formats with other --pretty formats 2019-03-25 19:26 [GSoC] Unify ref-filter formats with other --pretty formats Kapil Jain @ 2019-03-25 21:17 ` Olga Telezhnaya 2019-03-27 17:01 ` Kapil Jain 0 siblings, 1 reply; 9+ messages in thread From: Olga Telezhnaya @ 2019-03-25 21:17 UTC (permalink / raw) To: Kapil Jain; +Cc: git, Thomas Gummerer, Christian Couder пн, 25 мар. 2019 г. в 22:27, Kapil Jain <jkapil.cs@gmail.com>: > > Hi, > > Below are some two queries concerning > https://git.github.io/SoC-2019-Ideas/#unify-ref-filter-formats-with-other---pretty-formats > > Q1) > > In pretty.h & pretty.c: > void get_commit_format(const char *arg, struct rev_info *); > This function Parses given arguments from "arg", checks it for > correctness and * fill struct rev_info. > > In ref-filter.h & ref-filter.c: > int verify_ref_format(struct ref_format *format); > This function is Used to verify if the given format is correct and to > parse out the used atoms. > > Now, the verify_ref_format function can be used inside > get_commit_format function, hence reusing logic. > Is this a correct example to work on, for this project ? Hi! Yes, in my opinion your example looks like good starting point. > If not, please point out an example so as to understand the problem > statement better. > > Other than this I can't find any other example, for this project in > pretty.* and ref-filter.* > Perhaps some examples could be found in command specific files, right ? Other parts of the project are about reusing other ref-filter logic. For example, we could try to reuse format_ref_array_item() from ref-filter.h. I haven't dig into pretty.c logic much, but I guess it is possible to translate "pretty" formatting commands to ref-filter ones. That will allow us to remove similar logic from pretty.c. Our final goal is to minimise code duplication and to have one unified interface to extract all needed data from object and to print it properly. > > Q2) > About a recurring term 'atom' in ref-filter and pretty: > what is atom ? is it a piece of a whole document ? and what is meant > by used atoms ? I had the same question in my beginning. Please have a look at [1]. Another good question - what is object. You could ensure that you understand this by reading [2]. > > Thanks. [1] https://git-scm.com/docs/git-for-each-ref#_field_names [2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GSoC] Unify ref-filter formats with other --pretty formats 2019-03-25 21:17 ` Olga Telezhnaya @ 2019-03-27 17:01 ` Kapil Jain 2019-03-28 17:43 ` Olga Telezhnaya 0 siblings, 1 reply; 9+ messages in thread From: Kapil Jain @ 2019-03-27 17:01 UTC (permalink / raw) To: Olga Telezhnaya; +Cc: git, Thomas Gummerer, Christian Couder > On Tue, Mar 26, 2019 at 2:48 AM Olga Telezhnaya <olyatelezhnaya@gmail.com> wrote: >> Kapil Jain <jkapil.cs@gmail.com> wrote: > > Now, the verify_ref_format function can be used inside > > get_commit_format function, hence reusing logic. > > Is this a correct example to work on, for this project ? > > Hi! Yes, in my opinion your example looks like good starting point. I read through the code of both functions, and I think they are different. Please point out if I missed to see the similarity. or may be it seemed that way, because they both deal with different formats. So, first should a translating function (pretty to ref-filter) be written ? > > Other than this I can't find any other example, for this project in > > pretty.* and ref-filter.* > > Perhaps some examples could be found in command specific files, right ? > > Other parts of the project are about reusing other ref-filter logic. So, the project is not limited to reusing ref-filter logics in pretty, it is about reusing ref-filter logic wherever possible, right ? > For example, we could try to reuse format_ref_array_item() from > ref-filter.h. where can format_ref_array_item() be reused ? > I haven't dig into pretty.c logic much, but I guess it > is possible to translate "pretty" formatting commands to ref-filter > ones. That will allow us to remove similar logic from pretty.c. Our > final goal is to minimise code duplication and to have one unified > interface to extract all needed data from object and to print it > properly. I looked, and yes some, but not all pretty formats are translatable. For example: %GP, %p, %P. are not translatable to ref-filter. or is there a workaround to translate them ? It looks like to reuse ref-filter logic, a translator from pretty to ref-filter needs to be built. So, building a translator would be a starting point ? and then second step would be to recognise places where ref-filter can be reused, right ? > > what is atom ? is it a piece of a whole document ? and what is meant > > by used atoms ? > > I had the same question in my beginning. Please have a look at [1]. > Another good question - what is object. You could ensure that you > understand this by reading [2]. > > [1] https://git-scm.com/docs/git-for-each-ref#_field_names > [2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects Thanks, this helped. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GSoC] Unify ref-filter formats with other --pretty formats 2019-03-27 17:01 ` Kapil Jain @ 2019-03-28 17:43 ` Olga Telezhnaya 2019-03-29 13:53 ` Kapil Jain 0 siblings, 1 reply; 9+ messages in thread From: Olga Telezhnaya @ 2019-03-28 17:43 UTC (permalink / raw) To: Kapil Jain; +Cc: git, Thomas Gummerer, Christian Couder ср, 27 мар. 2019 г. в 20:01, Kapil Jain <jkapil.cs@gmail.com>: > > > On Tue, Mar 26, 2019 at 2:48 AM Olga Telezhnaya <olyatelezhnaya@gmail.com> wrote: > >> Kapil Jain <jkapil.cs@gmail.com> wrote: > > > Now, the verify_ref_format function can be used inside > > > get_commit_format function, hence reusing logic. > > > Is this a correct example to work on, for this project ? > > > > Hi! Yes, in my opinion your example looks like good starting point. > > I read through the code of both functions, and I think they are different. > Please point out if I missed to see the similarity. > > or may be it seemed that way, because they both deal with different formats. > So, first should a translating function (pretty to ref-filter) be written ? > > > > > Other than this I can't find any other example, for this project in > > > pretty.* and ref-filter.* > > > Perhaps some examples could be found in command specific files, right ? > > > > Other parts of the project are about reusing other ref-filter logic. > > So, the project is not limited to reusing ref-filter logics in pretty, > it is about reusing ref-filter logic wherever possible, right ? > > > For example, we could try to reuse format_ref_array_item() from > > ref-filter.h. > > where can format_ref_array_item() be reused ? > > > I haven't dig into pretty.c logic much, but I guess it > > is possible to translate "pretty" formatting commands to ref-filter > > ones. That will allow us to remove similar logic from pretty.c. Our > > final goal is to minimise code duplication and to have one unified > > interface to extract all needed data from object and to print it > > properly. > > I looked, and yes some, but not all pretty formats are translatable. > For example: %GP, %p, %P. are not translatable to ref-filter. or is > there a workaround to translate them ? I will try to answer to all your questions here in general way. Thomas, Christian, please correct me if you disagree. Our main goal is to simplify codebase, get rid of duplication of similar logic and, as a result, simplify adding new functionality. We also need to save backward compatibility, so we can't just delete some commands, rewrite them and change their interface (unfortunately). You are free to suggest your own ideas how to achieve these goals, and you are free to choose exact tasks. Yes, you are not limited only to pretty.c, but it is a good place where to start. I was an intern in winter 2017-2018 and I was trying to get rid of formatting logic in cat-file. You may try to do same thing in pretty.c. I guess it's easier to think how to reuse ref-filter in pretty.c because ref-filter has the most general interface between all these files. But, if you are sure that you have better idea - I am strongly recommend you to share it with the mailing list. Unfortunately, I can't consult you properly about structure of pretty.c. I guess that would be your first task of the internship to dive into it and think how to improve it. By the way, you could try to make more detailed documentation and that could be one of your first contributions. It will help you to understand the system better, and other contributors will be happy to read it. > > It looks like to reuse ref-filter logic, a translator from pretty to > ref-filter needs to be built. > So, building a translator would be a starting point ? > and then second step would be to recognise places where ref-filter can > be reused, right ? > > > > what is atom ? is it a piece of a whole document ? and what is meant > > > by used atoms ? > > > > I had the same question in my beginning. Please have a look at [1]. > > Another good question - what is object. You could ensure that you > > understand this by reading [2]. > > > > [1] https://git-scm.com/docs/git-for-each-ref#_field_names > > [2] https://git-scm.com/book/en/v2/Git-Internals-Git-Objects > > Thanks, this helped. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GSoC] Unify ref-filter formats with other --pretty formats 2019-03-28 17:43 ` Olga Telezhnaya @ 2019-03-29 13:53 ` Kapil Jain 2019-03-31 17:45 ` Kapil Jain 0 siblings, 1 reply; 9+ messages in thread From: Kapil Jain @ 2019-03-29 13:53 UTC (permalink / raw) To: Olga Telezhnaya; +Cc: git, Thomas Gummerer, Christian Couder On Thu, Mar 28, 2019 at 11:14 PM Olga Telezhnaya <olyatelezhnaya@gmail.com> wrote: > > Unfortunately, I can't consult you properly about structure of > pretty.c. I guess that would be your first task of the internship to > dive into it and think how to improve it. By the way, you could try to > make more detailed documentation and that could be one of your first > contributions. It will help you to understand the system better, and > other contributors will be happy to read it. ok, i will be reading pretty.c and will document its structure at required places. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GSoC] Unify ref-filter formats with other --pretty formats 2019-03-29 13:53 ` Kapil Jain @ 2019-03-31 17:45 ` Kapil Jain 2019-03-31 18:49 ` Thomas Gummerer 2019-03-31 19:28 ` Olga Telezhnaya 0 siblings, 2 replies; 9+ messages in thread From: Kapil Jain @ 2019-03-31 17:45 UTC (permalink / raw) To: Olga Telezhnaya; +Cc: git, Thomas Gummerer, Christian Couder On Fri, Mar 29, 2019 at 7:23 PM Kapil Jain <jkapil.cs@gmail.com> wrote: > > On Thu, Mar 28, 2019 at 11:14 PM Olga Telezhnaya > <olyatelezhnaya@gmail.com> wrote: > > > > Unfortunately, I can't consult you properly about structure of > > pretty.c. I guess that would be your first task of the internship to > > dive into it and think how to improve it. By the way, you could try to > > make more detailed documentation and that could be one of your first > > contributions. It will help you to understand the system better, and > > other contributors will be happy to read it. > i traced the cmd_log() to understand the point at which pretty.c could be used, i only got to userformat_find_requirements(). struct userformat_want { unsigned notes:1; unsigned source:1; }; what are notes and source flags used for ? olga: what approach did you follow to figure which logic in cat-file was redundant and that ref-filter could be reused there ? does it include picking any file, go through it entirely and then pick places to be replaced by ref-filter logic ? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GSoC] Unify ref-filter formats with other --pretty formats 2019-03-31 17:45 ` Kapil Jain @ 2019-03-31 18:49 ` Thomas Gummerer 2019-04-01 12:58 ` Kapil Jain 2019-03-31 19:28 ` Olga Telezhnaya 1 sibling, 1 reply; 9+ messages in thread From: Thomas Gummerer @ 2019-03-31 18:49 UTC (permalink / raw) To: Kapil Jain; +Cc: Olga Telezhnaya, git, Christian Couder On 03/31, Kapil Jain wrote: > On Fri, Mar 29, 2019 at 7:23 PM Kapil Jain <jkapil.cs@gmail.com> wrote: > > > > On Thu, Mar 28, 2019 at 11:14 PM Olga Telezhnaya > > <olyatelezhnaya@gmail.com> wrote: > > > > > > Unfortunately, I can't consult you properly about structure of > > > pretty.c. I guess that would be your first task of the internship to > > > dive into it and think how to improve it. By the way, you could try to > > > make more detailed documentation and that could be one of your first > > > contributions. It will help you to understand the system better, and > > > other contributors will be happy to read it. > > > > i traced the cmd_log() to understand the point at which pretty.c could > be used, i only got to userformat_find_requirements(). > > struct userformat_want { > unsigned notes:1; > unsigned source:1; > }; > > what are notes and source flags used for ? If you look at what userformat_find_requirements() does, calls strbuf_expand(), which in turn calls userformat_want_item(), which fills the 'userformat_want' struct based on the strbuf that has been passed. Now if we look at the caller of userformat_find_requirements(), which is cmd_log_init_finish(), you can see where 'w.notes' and 'w.source' is used. Just this parsing is probably not something that the ref-filter API can help too much with. I unfortunately don't have much experience with the pretty, or the ref-filter API. But rather than going into the details of the code already, I'd suggest first looking at what you actually want to replace (see for example the PRETTY FORMATS section in 'man git-log', what which verbs you can use in the ref-filter (see 'man git-for-each-ref') to achieve the same thing. Then you can see how one format is implemented in 'pretty.c', and see how a similar thing using the ref-filter is implemented in 'ref-filter.c'. E.g. the "%(objectname:short) %(contents:subject)" (this is missing coloring, but just to get you the idea) is similar to '--pretty=oneline'. Now you can try to find how 'oneline' is implemented in 'pretty.c', and you could translate that to use the 'ref-filter' API. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GSoC] Unify ref-filter formats with other --pretty formats 2019-03-31 18:49 ` Thomas Gummerer @ 2019-04-01 12:58 ` Kapil Jain 0 siblings, 0 replies; 9+ messages in thread From: Kapil Jain @ 2019-04-01 12:58 UTC (permalink / raw) To: Thomas Gummerer; +Cc: Olga Telezhnaya, git, Christian Couder On Mon, Apr 1, 2019 at 12:19 AM Thomas Gummerer <t.gummerer@gmail.com> wrote: > > If you look at what userformat_find_requirements() does, calls > strbuf_expand(), which in turn calls userformat_want_item(), which > fills the 'userformat_want' struct based on the strbuf that has been > passed. > > Now if we look at the caller of userformat_find_requirements(), which > is cmd_log_init_finish(), you can see where 'w.notes' and 'w.source' > is used. > i actually got to userformat_find_requirements() by tracing from cmd_log() itself. although i won't say i read the cmd_log_init_finish() line by line. will do. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [GSoC] Unify ref-filter formats with other --pretty formats 2019-03-31 17:45 ` Kapil Jain 2019-03-31 18:49 ` Thomas Gummerer @ 2019-03-31 19:28 ` Olga Telezhnaya 1 sibling, 0 replies; 9+ messages in thread From: Olga Telezhnaya @ 2019-03-31 19:28 UTC (permalink / raw) To: Kapil Jain; +Cc: git, Thomas Gummerer, Christian Couder вс, 31 мар. 2019 г. в 20:45, Kapil Jain <jkapil.cs@gmail.com>: > > On Fri, Mar 29, 2019 at 7:23 PM Kapil Jain <jkapil.cs@gmail.com> wrote: > > > > On Thu, Mar 28, 2019 at 11:14 PM Olga Telezhnaya > > <olyatelezhnaya@gmail.com> wrote: > > > > > > Unfortunately, I can't consult you properly about structure of > > > pretty.c. I guess that would be your first task of the internship to > > > dive into it and think how to improve it. By the way, you could try to > > > make more detailed documentation and that could be one of your first > > > contributions. It will help you to understand the system better, and > > > other contributors will be happy to read it. > > > > i traced the cmd_log() to understand the point at which pretty.c could > be used, i only got to userformat_find_requirements(). > > struct userformat_want { > unsigned notes:1; > unsigned source:1; > }; > > what are notes and source flags used for ? > > olga: what approach did you follow to figure which logic in cat-file > was redundant and that ref-filter could be reused there ? > does it include picking any file, go through it entirely and then pick > places to be replaced by ref-filter logic ? I just explored how the code works. You could see my commits here [1]. Oh, that's funny, I forgot that I started from creating pretty.h. I could choose between pretty and cat-file, and I made the choice randomly. In cat-file, interface was so close to ref-filter, but the way of obtaining data was different, and formatting logic was coded twice. We decided that cat-file gets the data more efficiently, and I changed ref-filter logic, it works faster now. Then I needed to reuse formatting logic, and I am still working on that (do not worry, it must not be a reason for merge conflicts). I guess you will have another workflow: I don't know anything about how pretty gets the data, but the interface differs a lot. So you will have another tasks. If you have enough skills to debug the code, I definitely suggest you to go through all formatting process step-by-step (both for pretty and ref-filter) for different type of input, that will explain you a lot and maybe that will give you some ideas how to achieve the goals better. 1.5 years ago I didn't know how to use gdb properly, and it was much more important for me to start doing just something, that's why I used debug prints. The meaning is the same anyway. The most important advice that I can give you: think about whole process, then try to design your steps so that they could be as small as possible. I mean, it's not a good idea to make big patches (more than 3-5 commits), especially at the beginning. [1] https://github.com/git/git/commits?author=telezhnaya ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-04-01 12:59 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-03-25 19:26 [GSoC] Unify ref-filter formats with other --pretty formats Kapil Jain 2019-03-25 21:17 ` Olga Telezhnaya 2019-03-27 17:01 ` Kapil Jain 2019-03-28 17:43 ` Olga Telezhnaya 2019-03-29 13:53 ` Kapil Jain 2019-03-31 17:45 ` Kapil Jain 2019-03-31 18:49 ` Thomas Gummerer 2019-04-01 12:58 ` Kapil Jain 2019-03-31 19:28 ` Olga Telezhnaya
Code repositories for project(s) associated with this public inbox https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).