git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
* [RFC 0/4] ref-filter: remove printing from formatting logic
@ 2018-03-13 10:25 Оля Тележная
  2018-03-13 19:26 ` Martin Ågren
  0 siblings, 1 reply; 3+ messages in thread
From: Оля Тележная @ 2018-03-13 10:25 UTC (permalink / raw)
  To: git

The main idea of the patch is, if you want to format the output by
ref-filter, you should have an ability to work with errors by yourself
if you want to.
So I decided not to touch signature of show_ref_array_item(), but to
move all printing (I mean errors) to it. So that we could invoke
format_ref_array_item() and be sure that we cold handle errors by
ourselves.

The patch is not finished, but I decided to show it to you. There are
still many places where we could die in the middle of formatting
process. But, if you like the general idea, I will finish and re-send
it.

Another question is about verify_ref_format(). Do we need to allow its
users also to manage errors by themselves? I left the old scenario,
printing everything in verify_ref_format() and die. If you have better
ideas, please share them.

Thanks a lot!
Olga

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC 0/4] ref-filter: remove printing from formatting logic
  2018-03-13 10:25 [RFC 0/4] ref-filter: remove printing from formatting logic Оля Тележная
@ 2018-03-13 19:26 ` Martin Ågren
  2018-03-14 13:44   ` Оля Тележная
  0 siblings, 1 reply; 3+ messages in thread
From: Martin Ågren @ 2018-03-13 19:26 UTC (permalink / raw)
  To: Оля
	Тележная
  Cc: git

Hi Olga

On 13 March 2018 at 11:25, Оля Тележная <olyatelezhnaya@gmail.com> wrote:
> The main idea of the patch is, if you want to format the output by
> ref-filter, you should have an ability to work with errors by yourself
> if you want to.
> So I decided not to touch signature of show_ref_array_item(), but to
> move all printing (I mean errors) to it. So that we could invoke
> format_ref_array_item() and be sure that we cold handle errors by
> ourselves.
>
> The patch is not finished, but I decided to show it to you. There are
> still many places where we could die in the middle of formatting
> process. But, if you like the general idea, I will finish and re-send
> it.
>
> Another question is about verify_ref_format(). Do we need to allow its
> users also to manage errors by themselves? I left the old scenario,
> printing everything in verify_ref_format() and die. If you have better
> ideas, please share them.

I think it is a good idea to stop die-ing in "libgit". This seems like a
good way of achieving that, or isolating the issue. Do you have any
particular use-case for this, i.e., are you setting up the stage for a
patch "5" where you add a new user of one of these?

I do wonder whether a helper function to call strbuf_addstr() and return
-1 would be a good idea though. I mentioned it in patch 2, then with
patches 3 and 4, it started to seem like a reasonably good idea. It
would be a shame if this sort of "boilerplate" for handling errors could
have an impact on code clarity / obviousness.

Another issue is whether passing NULL for an error-strbuf should be a
way of saying "I don't care; die() so I do not have to". Well, right now
I guess passing NULL would indeed terminate the program. ;-) Such a
construct might be another reason for providing error_strbuf_addstr()...
Of course, it also means we keep die-ing in libgit..

I feel I'm just talking out loud. Maybe you find my input useful.

Martin

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [RFC 0/4] ref-filter: remove printing from formatting logic
  2018-03-13 19:26 ` Martin Ågren
@ 2018-03-14 13:44   ` Оля Тележная
  0 siblings, 0 replies; 3+ messages in thread
From: Оля Тележная @ 2018-03-14 13:44 UTC (permalink / raw)
  To: Martin Ågren; +Cc: git

2018-03-13 22:26 GMT+03:00 Martin Ågren <martin.agren@gmail.com>:
> Hi Olga
>
> On 13 March 2018 at 11:25, Оля Тележная <olyatelezhnaya@gmail.com> wrote:
>> The main idea of the patch is, if you want to format the output by
>> ref-filter, you should have an ability to work with errors by yourself
>> if you want to.
>> So I decided not to touch signature of show_ref_array_item(), but to
>> move all printing (I mean errors) to it. So that we could invoke
>> format_ref_array_item() and be sure that we cold handle errors by
>> ourselves.
>>
>> The patch is not finished, but I decided to show it to you. There are
>> still many places where we could die in the middle of formatting
>> process. But, if you like the general idea, I will finish and re-send
>> it.
>>
>> Another question is about verify_ref_format(). Do we need to allow its
>> users also to manage errors by themselves? I left the old scenario,
>> printing everything in verify_ref_format() and die. If you have better
>> ideas, please share them.
>
> I think it is a good idea to stop die-ing in "libgit". This seems like a
> good way of achieving that, or isolating the issue. Do you have any
> particular use-case for this, i.e., are you setting up the stage for a
> patch "5" where you add a new user of one of these?

Yes, I want to reuse formatting part in cat-file command. In cat-file
sometimes we have an error but we want to continue our work and check
all other sha1s. But, anyway, I find these changes useful not only for
cat-file.

>
> I do wonder whether a helper function to call strbuf_addstr() and return
> -1 would be a good idea though. I mentioned it in patch 2, then with
> patches 3 and 4, it started to seem like a reasonably good idea. It
> would be a shame if this sort of "boilerplate" for handling errors could
> have an impact on code clarity / obviousness.

I am also not sure if the code will be intuitive enough.

>
> Another issue is whether passing NULL for an error-strbuf should be a
> way of saying "I don't care; die() so I do not have to". Well, right now
> I guess passing NULL would indeed terminate the program. ;-) Such a
> construct might be another reason for providing error_strbuf_addstr()...
> Of course, it also means we keep die-ing in libgit..
>
> I feel I'm just talking out loud. Maybe you find my input useful.

I do so! Thanks a lot.
I fixed all that you mentioned, you could find new code here if you want:
https://github.com/telezhnaya/git/commits/prepare
I will not re-send it to the mailing list now. I want to finish the
patch at first, there are still some die() calls.
If anyone has other thoughts or ideas - please share them.

>
> Martin

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-13 10:25 [RFC 0/4] ref-filter: remove printing from formatting logic Оля Тележная
2018-03-13 19:26 ` Martin Ågren
2018-03-14 13:44   ` Оля Тележная

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

Archives are clonable:
	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

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

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