From: Paul-Sebastian Ungureanu <ungureanupaulsebastian@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH 2/6] tree-walk: Add three new gentle helpers
Date: Thu, 19 Jul 2018 02:11:49 +0300 [thread overview]
Message-ID: <ba38bdd0-c1c3-cded-0e18-f21e0d7fd9a8@gmail.com> (raw)
In-Reply-To: <xmqqin5dofor.fsf@gitster-ct.c.googlers.com>
Hello,
On 17.07.2018 21:55, Junio C Hamano wrote:
> I wonder if the GENTLY option should apply to update_tree_entry()
> the same way as it would to the other codepaths that currently die
> to express "we were handed this string by the caller and told to
> give back object ID the string represents, and we found no good
> answer". In this one (and the "bad ref" one), the existing failures
> in these two codepaths are not "we got a string and that does not
> resolve to an object name", but "we didn't have the data to work on
> to begin with (either a corrupt tree object or a corrupt ref").
>
> In other words, it's not like "We were given HEAD:no-such-path and
> there is no such path in that tree"; it is "We tried to read HEAD:
> tree for no-such-path in it, but the tree was corrupt and we couldn't
> even tell if such a path is or is not in it", no?
I can definitely say there is a clear difference between these
two cases, but I am not entirely sure how `GENTLY` should apply to
`update_tree_entry()`.
On one side, even before this patch, there was the gentle version
of this function, `update_tree_entry_gently()`, which could still die.
And it makes sense. It should be ok to call `die()` when there was
detected a "bigger" issue.
On the other side, in some cases like `read_ref_at()` I think that it
could be useful if the caller could handle any error (which is what
patches 3/6 and 4/6 try to accomplish).
I really do not know which way would be the best in this particular case.
Best,
Paul
next prev parent reply other threads:[~2018-07-18 23:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-17 12:06 [RFC PATCH 0/6] Add gentle alternative for `get_oid()` Paul-Sebastian Ungureanu
2018-07-17 12:06 ` [RFC PATCH 1/6] sha1-name: Add `GET_OID_GENTLY` flag Paul-Sebastian Ungureanu
2018-07-17 12:06 ` [RFC PATCH 2/6] tree-walk: Add three new gentle helpers Paul-Sebastian Ungureanu
2018-07-17 18:55 ` Junio C Hamano
2018-07-18 23:11 ` Paul-Sebastian Ungureanu [this message]
2018-07-17 12:06 ` [RFC PATCH 3/6] refs.c: Teach `read_ref_at()` to accept `GET_OID_GENTLY` flag Paul-Sebastian Ungureanu
2018-07-17 12:06 ` [RFC PATCH 4/6] sha1-name: Teach `get_oid_basic()` to be gentle Paul-Sebastian Ungureanu
2018-07-17 12:06 ` [RFC PATCH 5/6] sha1-name: Teach `get_oid_with_context[_1]()` " Paul-Sebastian Ungureanu
2018-07-17 19:13 ` Junio C Hamano
2018-07-18 23:14 ` Paul-Sebastian Ungureanu
2018-07-17 12:06 ` [RFC PATCH 6/6] sha1-name: Add gentle alternative for `get_oid()` Paul-Sebastian Ungureanu
2018-07-17 17:45 ` [RFC PATCH 0/6] " Duy Nguyen
2018-07-18 23:03 ` Paul-Sebastian Ungureanu
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=ba38bdd0-c1c3-cded-0e18-f21e0d7fd9a8@gmail.com \
--to=ungureanupaulsebastian@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).