diff mbox series

[2/4] sequencer: do not translate parameters to error_resolve_conflict()

Message ID 4684d54aeb3e00c96ba581c824a04e47b7236db7.1660828108.git.git@grubix.eu (mailing list archive)
State Accepted
Commit 1c8dfc3674fd9da7ded669b706b292ee2074db73
Headers show
Series sequencer: clarify translations | expand

Commit Message

Michael J Gruber Aug. 18, 2022, 1:13 p.m. UTC
`error_resolve_conflict()` checks the untranslated action_name
parameter, so pass it as is.

Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Michael J Gruber <git@grubix.eu>
---
 sequencer.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Ævar Arnfjörð Bjarmason Aug. 18, 2022, 3:01 p.m. UTC | #1
On Thu, Aug 18 2022, Michael J Gruber wrote:

> `error_resolve_conflict()` checks the untranslated action_name
> parameter, so pass it as is.
>
> Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Signed-off-by: Michael J Gruber <git@grubix.eu>
> ---
>  sequencer.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index 51d75dfbe1..8b32b239b9 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -537,7 +537,7 @@ static struct tree *empty_tree(struct repository *r)
>  static int error_dirty_index(struct repository *repo, struct replay_opts *opts)
>  {
>  	if (repo_read_index_unmerged(repo))
> -		return error_resolve_conflict(_(action_name(opts)));
> +		return error_resolve_conflict(action_name(opts));
>  
>  	error(_("your local changes would be overwritten by %s."),
>  		_(action_name(opts)));
> @@ -3753,7 +3753,7 @@ static int do_reset(struct repository *r,
>  	init_checkout_metadata(&unpack_tree_opts.meta, name, &oid, NULL);
>  
>  	if (repo_read_index_unmerged(r)) {
> -		ret = error_resolve_conflict(_(action_name(opts)));
> +		ret = error_resolve_conflict(action_name(opts));
>  		goto cleanup;
>  	}

Perhaps we should have the error_resolve_conflict() function take a
"enum replay_action" instead? We could just do this more isolated
change, but perhaps that "while-we're-at-it" would be acceptable to
reduce the risk of running with this particular set of scissors.

Then we could note in a comment in that function that we do not want to
translate the string we'd get from action_name()...
Michael J Gruber Aug. 18, 2022, 3:23 p.m. UTC | #2
Am Do., 18. Aug. 2022 um 17:02 Uhr schrieb Ævar Arnfjörð Bjarmason
<avarab@gmail.com>:
>
>
> On Thu, Aug 18 2022, Michael J Gruber wrote:
>
> > `error_resolve_conflict()` checks the untranslated action_name
> > parameter, so pass it as is.
> >
> > Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> > Signed-off-by: Michael J Gruber <git@grubix.eu>
> > ---
> >  sequencer.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/sequencer.c b/sequencer.c
> > index 51d75dfbe1..8b32b239b9 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -537,7 +537,7 @@ static struct tree *empty_tree(struct repository *r)
> >  static int error_dirty_index(struct repository *repo, struct replay_opts *opts)
> >  {
> >       if (repo_read_index_unmerged(repo))
> > -             return error_resolve_conflict(_(action_name(opts)));
> > +             return error_resolve_conflict(action_name(opts));
> >
> >       error(_("your local changes would be overwritten by %s."),
> >               _(action_name(opts)));
> > @@ -3753,7 +3753,7 @@ static int do_reset(struct repository *r,
> >       init_checkout_metadata(&unpack_tree_opts.meta, name, &oid, NULL);
> >
> >       if (repo_read_index_unmerged(r)) {
> > -             ret = error_resolve_conflict(_(action_name(opts)));
> > +             ret = error_resolve_conflict(action_name(opts));
> >               goto cleanup;
> >       }
>
> Perhaps we should have the error_resolve_conflict() function take a
> "enum replay_action" instead? We could just do this more isolated
> change, but perhaps that "while-we're-at-it" would be acceptable to
> reduce the risk of running with this particular set of scissors.
>
> Then we could note in a comment in that function that we do not want to
> translate the string we'd get from action_name()...

Rather than setting out to do that, I'd retract 2/3/4 just to get 1
done, which was my original motivation ... or switch git to C again as
I did for a while in the past ...
Junio C Hamano Aug. 18, 2022, 8:30 p.m. UTC | #3
Michael J Gruber <git@grubix.eu> writes:

> Rather than setting out to do that, I'd retract 2/3/4 just to get 1
> done, which was my original motivation ... or switch git to C again as
> I did for a while in the past ...

While I found 4/4 a bit questionable, these early three patches
looked eminently sensible to me.
Johannes Schindelin Aug. 19, 2022, 9:26 a.m. UTC | #4
Hi Ævar,

On Thu, 18 Aug 2022, Ævar Arnfjörð Bjarmason wrote:

> On Thu, Aug 18 2022, Michael J Gruber wrote:
>
> > `error_resolve_conflict()` checks the untranslated action_name
> > parameter, so pass it as is.
> >
> > Suggested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> > Signed-off-by: Michael J Gruber <git@grubix.eu>
> > ---
> >  sequencer.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/sequencer.c b/sequencer.c
> > index 51d75dfbe1..8b32b239b9 100644
> > --- a/sequencer.c
> > +++ b/sequencer.c
> > @@ -537,7 +537,7 @@ static struct tree *empty_tree(struct repository *r)
> >  static int error_dirty_index(struct repository *repo, struct replay_opts *opts)
> >  {
> >  	if (repo_read_index_unmerged(repo))
> > -		return error_resolve_conflict(_(action_name(opts)));
> > +		return error_resolve_conflict(action_name(opts));
> >
> >  	error(_("your local changes would be overwritten by %s."),
> >  		_(action_name(opts)));
> > @@ -3753,7 +3753,7 @@ static int do_reset(struct repository *r,
> >  	init_checkout_metadata(&unpack_tree_opts.meta, name, &oid, NULL);
> >
> >  	if (repo_read_index_unmerged(r)) {
> > -		ret = error_resolve_conflict(_(action_name(opts)));
> > +		ret = error_resolve_conflict(action_name(opts));
> >  		goto cleanup;
> >  	}
>
> Perhaps we should have the error_resolve_conflict() function take a
> "enum replay_action" instead?

We could do that. We could also just delete the sequencer code. It's just
that both are a bad idea.

Ciao,
Johannes
Junio C Hamano Aug. 19, 2022, 5:36 p.m. UTC | #5
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

>> Perhaps we should have the error_resolve_conflict() function take a
>> "enum replay_action" instead?
>
> We could do that. We could also just delete the sequencer code. It's just
> that both are a bad idea.

Sorry, but I do not quite understand this comment.  You may think
some parts of the sequencer code are a bad idea but I think overall
it is eminently useful and usable enough that it does not make sense
to "just delete the sequencer code"---if there are things we find
bad ideas in there, we should fix them instead, no?

In any case, can you keep the conversation more civil?  I have to
say that between you two, you may by no means be the only one who is
unnecessarily abrasive, but if you do not understand why the other
side suggests a solution you feel you do not like, you can ask more
constructively why they think it is a good idea, without assuming
that they are doing so only to block you.  Or explain why you think
it is a bad idea by showing the consequences of their solution, e.g.
"there are 20 callsites, among which only 1 has the enum readily
available so it would be a lot of churn to give the other 19 the
enum, even though the error helper may become simpler with a single
switch() statement if we allow it to take an enum." or something (I
know this function is called only from very few places, so 1 out of
20 is a totally made-up reasoning that would not apply in this case,
but you get the idea).

Thanks.
Johannes Schindelin Aug. 22, 2022, 1:53 p.m. UTC | #6
Hi Junio,

[Michael, I do not consider what I wrote below relevant for your patch
series, you may ignore it if you want]

On Fri, 19 Aug 2022, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Perhaps we should have the error_resolve_conflict() function take a
> >> "enum replay_action" instead?
> >
> > We could do that. We could also just delete the sequencer code. It's just
> > that both are a bad idea.
>
> Sorry, but I do not quite understand this comment.

I expected a seasoned reviewer to offer such a suggestion only after
looking up (or remembering) how `error_resolve_conflict()` is defined, and
where, and where its callers are.

After all, many suggestions that come to mind during a review turn out to
be a bad idea when considering them carefully, and if that can be
determined before the mail is sent, everybody wins back some time.

In this instance, `error_resolve_conflict()` is declared in `advice.h`.
The suggestion to use a sequencer-specific data type there sounds...
controversial. But okay, maybe there are good reasons to suggest that.

Let's look at the callers. Two callers in `sequencer.c`. Okay, maybe it
makes a bit more sense. But one caller in `advice.c`? Let's dig deeper.

That caller in `advice.c` is `die_resolve_conflict()`, which is called in
the built-ins `commit`, `merge-recursive`, `merge` and `pull`.

Those callers have nothing to do with the sequencer, therefore it is a bad
idea to suggest using a sequencer-specific data type in that call chain.

From my perspective, that is enough to retire the suggestion.

When I wrote what I wrote, I thought that it was a pretty quick thing to
determine, so quick that I really expected to not see such a suggestion on
the mailing list in the first place.

In hindsight, I understand that you would have had to look at the code,
and not just at the patch, to see this. And therefore it is probably not
quite as obvious as I thought. I did not expect new contributors to be
able to analyze this quickly, but a Git mailing list regular, yes.

For my flippant response, I apologize.

As for the suggestion I criticized: I stand by my assessment. It is not a
good idea, and it was not necessary to send it out before doing a cursory
sanity check. We want code contribution to have a high quality, and the
code reviews should meet at least the same bar.

Ciao,
Dscho
Junio C Hamano Aug. 22, 2022, 4:12 p.m. UTC | #7
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> ... We want code contribution to have a high quality, and the
> code reviews should meet at least the same bar.

I like that one.  Ævar is not alone, but many of us often throw an
unrelated "observation" into a review thread that is a total
tangent.  While I do not think it is necessarily a bad thing,
because these tangential discussions often turn into separate idea
that lead to improvements, we should learn to (1) mark a tangent
clearly as such and (2) keep the quality of the tangent reasonably
high.

Thanks.
diff mbox series

Patch

diff --git a/sequencer.c b/sequencer.c
index 51d75dfbe1..8b32b239b9 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -537,7 +537,7 @@  static struct tree *empty_tree(struct repository *r)
 static int error_dirty_index(struct repository *repo, struct replay_opts *opts)
 {
 	if (repo_read_index_unmerged(repo))
-		return error_resolve_conflict(_(action_name(opts)));
+		return error_resolve_conflict(action_name(opts));
 
 	error(_("your local changes would be overwritten by %s."),
 		_(action_name(opts)));
@@ -3753,7 +3753,7 @@  static int do_reset(struct repository *r,
 	init_checkout_metadata(&unpack_tree_opts.meta, name, &oid, NULL);
 
 	if (repo_read_index_unmerged(r)) {
-		ret = error_resolve_conflict(_(action_name(opts)));
+		ret = error_resolve_conflict(action_name(opts));
 		goto cleanup;
 	}