вс, 31 мар. 2019 г. в 20:45, Kapil Jain <jkapil.cs@xxxxxxxxx>:
>
> On Fri, Mar 29, 2019 at 7:23 PM Kapil Jain <jkapil.cs@xxxxxxxxx> wrote:
> >
> > On Thu, Mar 28, 2019 at 11:14 PM Olga Telezhnaya
> > <olyatelezhnaya@xxxxxxxxx> 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
