ср, 27 мар. 2019 г. в 20:01, Kapil Jain <jkapil.cs@xxxxxxxxx>: > > > On Tue, Mar 26, 2019 at 2:48 AM Olga Telezhnaya <olyatelezhnaya@xxxxxxxxx> wrote: > >> Kapil Jain <jkapil.cs@xxxxxxxxx> 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.
