git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / code / Atom feed
From: "Оля Тележная" <olyatelezhnaya@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git <git@vger.kernel.org>
Subject: Re: [PATCH v2 01/18] cat-file: split expand_atom into 2 functions
Date: Tue, 16 Jan 2018 10:22:23 +0300	[thread overview]
Message-ID: <CAL21BmmmX5-uisj+_=sDHwJO=fpXc41Wriw+uuxtR=gOio-HZQ@mail.gmail.com> (raw)
In-Reply-To: <20180115220946.GF4778@sigill.intra.peff.net>

2018-01-16 1:09 GMT+03:00 Jeff King <peff@peff.net>:
> On Mon, Jan 15, 2018 at 04:33:35PM -0500, Jeff King wrote:
>
>> That works, but I don't think it's where we want to end up in the long
>> run.

I absolutely agree, I want to merge current edits and then continue
migrating process. And hopefully second part of the function will also
be removed.

>> Because:
>>
>>   1. We still have the set of formats duplicated between expand_atom()
>>      and the "preparation" step. It's just that the preparation is now
>>      in ref-filter.c. What happens if ref-filter.c learns new formatting
>>      placeholders (or options for those placeholders) that cat-file.c
>>      doesn't, or vice versa? The two have to be kept in sync.
>>
>>   2. We're missing out on all of the other placeholders that ref-filter
>>      knows about. Not all of them are meaningful (e.g., %(refname)
>>      wouldn't make sense here), but part of our goal is to support the
>>      same set of placeholders as much as possible. Some obvious ones
>>      that ought to work for cat-file: %(objectname:short), %(if), and
>>      things like %(subject) when the appropriate object type is used.
>>
>> In other words, I think the endgame is that expand_atom() isn't there at
>> all, and we're calling the equivalent of format_ref_item() for each
>> object (except that in a unified formatting world, it probably doesn't
>> have the word "ref" in it, since that's just one of the items a caller
>> might pass in).

Agree! I want to merge current edits, then create format.h file and
make some renames, then finish migrating process to new format.h and
support all new meaningful tags.

>
> I read carefully up through about patch 6, and then skimmed through the
> rest. I think we really want to push this in the direction of more
> unification, as above. I know that the patches here may be a step on the
> way, but I had a hard time evaluating each patch to see if it was
> leading us in the right direction.
>
> I think what would help for reviewing this is:
>
>   1. Start with a cover letter that makes it clear what the end state of
>      the series is, and why that's the right place to end up.
>
>   2. Include a rough roadmap of the patches in the cover letter.
>      Hopefully they should group into a few obvious steps (like "in
>      patches 1-5, we're teaching ref-filter to support everything that
>      cat-file can do, then in 6-10 we're preparing cat-file for the
>      conversion, and then in 11 we do the conversion"). If it doesn't
>      form a coherent narrative, then it may be worth stepping back and
>      thinking about combining or reordering the patches in a different
>      way, so that the progression becomes more plain.
>
>      I think one of the things that makes the progression here hard to
>      understand (for me, anyway) is that it's "inside out" of what I'd
>      expect. There's a lot of code movement happening first, and then
>      refactoring and simplifying after that. So between those two steps,
>      there's a lot of interim ugliness (e.g., having to reach across
>      module boundaries to look at expand_data). It's hard to tell when
>      looking at each individual patch how necessary the ugliness is, and
>      whether and when it's going to go away later in the series.
>
> There's a lot of good work here, and you've figured out a lot about how
> the two systems function. I think we just need to rearrange things a bit
> to make sure each step is moving in the right direction.
>
> -Peff

As I said, I am sure that I will continue working on that, so this is
not the end state. So I am not sure that I am able to write finalizing
messages for now. But, if we merge current edits, it will be much
easier for me to continue working on that (next patch would be about
creating format.h and I am afraid of some merge conflicts if I will
develop absolutely all process from start to finish in my branch, it
takes time. It's not a big problem, but, if we find final goal
worthwhile, so maybe we could go to it step-by-step).

  reply	other threads:[~2018-01-16  7:22 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 13:05 [PATCH 01/20] " Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 18/20] cat-file: add split_on_whitespace flag Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 06/20] cat-file: start migrating to ref-filter Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 14/20] cat-file: make populate_value global Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 13/20] cat-file: start use ref_array_item struct Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 16/20] cat-file: get rid of expand_atom_into_fields Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 10/20] cat-file: simplify expand_atom function Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 19/20] cat-file: move skip_object_info into ref-filter Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 20/20] cat-file: make cat_file_info variable independent Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 12/20] cat-file: rename variable in ref-filter Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 03/20] cat-file: rename variables " Olga Telezhnaya
2018-01-09 22:04   ` Junio C Hamano
2018-01-10  7:07     ` Оля Тележная
2018-01-09 13:05 ` [PATCH 15/20] cat-file: start reusing populate_value Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 08/20] cat-file: remove unused code Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 02/20] cat-file: reuse struct ref_format Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 11/20] cat-file: get rid of duplicate checking Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 17/20] cat-file: add is_cat flag in ref-filter Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 05/20] cat-file: move struct expand_data into ref-filter Olga Telezhnaya
2018-01-09 13:05 ` [PATCH 07/20] cat-file: reuse parse_ref_filter_atom Olga Telezhnaya
2018-01-09 23:32   ` Junio C Hamano
2018-01-09 13:05 ` [PATCH 04/20] cat-file: make valid_atoms as a function parameter Olga Telezhnaya
2018-01-09 22:16   ` Junio C Hamano
2018-01-09 13:05 ` [PATCH 09/20] cat-file: get rid of goto in ref-filter Olga Telezhnaya
2018-01-10  9:36 ` [PATCH v2 01/18] cat-file: split expand_atom into 2 functions Olga Telezhnaya
2018-01-10  9:36   ` [PATCH v2 07/18] cat-file: remove unused code Olga Telezhnaya
2018-01-10  9:36   ` [PATCH v2 15/18] ref-filter: add is_cat flag Olga Telezhnaya
2018-01-10  9:36   ` [PATCH v2 08/18] ref-filter: get rid of goto Olga Telezhnaya
2018-01-10  9:36   ` [PATCH v2 09/18] cat-file: simplify expand_atom function Olga Telezhnaya
2018-01-10  9:36   ` [PATCH v2 05/18] cat-file: start migrating to ref-filter Olga Telezhnaya
2018-01-10  9:36   ` [PATCH v2 13/18] cat-file: start reusing populate_value Olga Telezhnaya
2018-01-10  9:36   ` [PATCH v2 11/18] cat-file: start use ref_array_item struct Olga Telezhnaya
2018-01-10  9:36   ` [PATCH v2 17/18] cat-file: move skip_object_info into ref-filter Olga Telezhnaya
2018-01-10  9:36   ` [PATCH v2 10/18] cat-file: get rid of duplicate checking Olga Telezhnaya
2018-01-10  9:36   ` [PATCH v2 14/18] ref-filter: get rid of expand_atom_into_fields Olga Telezhnaya
2018-01-10  9:36   ` [PATCH v2 16/18] ref_format: add split_on_whitespace flag Olga Telezhnaya
2018-01-10  9:36   ` [PATCH v2 06/18] ref-filter: reuse parse_ref_filter_atom Olga Telezhnaya
2018-01-10  9:36   ` [PATCH v2 18/18] ref-filter: make cat_file_info independent Olga Telezhnaya
2018-01-10  9:36   ` [PATCH v2 04/18] cat-file: move struct expand_data into ref-filter Olga Telezhnaya
2018-01-15 21:44     ` Jeff King
2018-01-16  7:00       ` Оля Тележная
2018-01-17 21:45         ` Jeff King
2018-01-18  5:56           ` Оля Тележная
2018-01-10  9:36   ` [PATCH v2 03/18] ref-filter: make valid_atom as function parameter Olga Telezhnaya
2018-01-15 21:42     ` Jeff King
2018-01-16  6:55       ` Оля Тележная
2018-01-17 21:43         ` Jeff King
2018-01-17 22:39           ` Christian Couder
2018-01-18  6:20             ` Оля Тележная
2018-01-18 11:49               ` Оля Тележная
2018-01-18 14:23                 ` Christian Couder
2018-01-19 12:24                   ` Оля Тележная
2018-01-19 15:48                     ` Christian Couder
2018-01-19 17:14               ` Christian Couder
2018-01-19 17:22                 ` Оля Тележная
2018-01-19 17:57                   ` Christian Couder
2018-01-19 17:23                 ` Jeff King
2018-01-19 17:31                   ` Christian Couder
2018-01-19 18:47                   ` Junio C Hamano
2018-01-19 20:12                     ` Jeff King
2018-01-10  9:36   ` [PATCH v2 02/18] cat-file: reuse struct ref_format Olga Telezhnaya
2018-01-15 21:37     ` Jeff King
2018-01-16  9:45       ` Оля Тележная
2018-01-10  9:36   ` [PATCH v2 12/18] ref-filter: make populate_value global Olga Telezhnaya
2018-01-15 21:33   ` [PATCH v2 01/18] cat-file: split expand_atom into 2 functions Jeff King
2018-01-15 22:09     ` Jeff King
2018-01-16  7:22       ` Оля Тележная [this message]
2018-01-17 21:49         ` Jeff King
2018-01-17 23:04           ` Christian Couder
2018-01-18  6:22             ` Оля Тележная
2018-01-18  8:45               ` Christian Couder

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to='CAL21BmmmX5-uisj+_=sDHwJO=fpXc41Wriw+uuxtR=gOio-HZQ@mail.gmail.com' \
    --to=olyatelezhnaya@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --subject='Re: [PATCH v2 01/18] cat-file: split expand_atom into 2 functions' \
    /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

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://7fh6tueqddpjyxjmgtdiueylzoqt6pt7hec3pukyptlmohoowvhde4yd.onion/inbox.comp.version-control.git
	nntp://ie5yzdi7fg72h7s4sdcztq5evakq23rdt33mfyfcddc5u3ndnw24ogqd.onion/inbox.comp.version-control.git
	nntp://4uok3hntl7oi7b4uf4rtfwefqeexfzil2w6kgk2jn5z2f764irre7byd.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git