git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Olga Telezhnaya <olyatelezhnaya@gmail.com>
To: Kapil Jain <jkapil.cs@gmail.com>
Cc: git <git@vger.kernel.org>, Thomas Gummerer <t.gummerer@gmail.com>,
	Christian Couder <christian.couder@gmail.com>
Subject: Re: [GSoC] Unify ref-filter formats with other --pretty formats
Date: Sun, 31 Mar 2019 22:28:50 +0300	[thread overview]
Message-ID: <CAL21Bmk+=id0jat1O1vQLXBV=snXgK81qFit8_xXNogQM31Pyw@mail.gmail.com> (raw)
In-Reply-To: <CAMknYEPN2rPsX8CcJVosi-S1W8bLTmMMvgS8E-SwyR74gevtcA@mail.gmail.com>

вс, 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

      parent reply	other threads:[~2019-03-31 19:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAL21Bmk+=id0jat1O1vQLXBV=snXgK81qFit8_xXNogQM31Pyw@mail.gmail.com' \
    --to=olyatelezhnaya@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jkapil.cs@gmail.com \
    --cc=t.gummerer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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 NNTP newsgroup(s).