Re: [PATCH v4] [GSOC] cherry-pick: use better advice message

"ZheNing Hu via GitGitGadget" [off-list ref] writes:

From: ZheNing Hu <redacted>

In the past, git cherry-pick would print such advice when
there was a conflict:
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

In our log messages, we desciribe the current state in the present
tense.

It may be worth mentioning that this is because the program
originally was about picking only one commit and the hint was
inherited from those days.  Or it may not.  I dunno.

But in fact, when we want to cherry-pick multiple commits,
we should not use "git commit" after resolving conflicts, which
will make Git generate some errors. We should recommend users to
use `git cherry-pick --continue`, `git cherry-pick --abort`, just
like git rebase does.

I am not sure "should not" is the right phrase.  Also it does not
help readers to have a vague "generate some errors" than not saying
anything---it leaves readers puzzled with "what errors???"

Whether picking a single commit or a series of commits, after
resolving conflicts in the current step, wouldn't

    $ git commit ;# to conclude the resolution
    $ git cherry-pick --continue

do the right thing?

This is the improved advice:

It may be an improved advice, but just omit it and say something
like:

	Suggest use of "git cherry-pick --contiue", so that it would
	also apply to cases where multiple commits are being picked.

The actual message does not have to be reproduced here, as it is in
the source, and it can be seen in the test ;-)

That would make the proposed log message conform to our norm,
i.e. brief description of what happens with the current system,
followed by description of the perceived problem, followed by
an order to the codebase to become different in a specific way
that solves the problem.

Taken together, perhaps

	"git cherry-pick", upon seeing a conflict, says:

	    hint: ...

	as if running "git commit" to conclude the resolution of
	this single step were the end of the story.  This stems from
	the fact that the command originally was to pick a single
	commit and not a range of commits, and the message was
	written back then and has not been adjusted.

	When picking a range of commits and the command stops with a
	conflict in the middle of the range, however, after
	resolving the conflict and (optionally) recording the result
	with "git commit", the user has to run "git cherry-pick
	--continue" to have the rest of the range dealt with,
	"--skip" to drop the current commit, or "--abort" to discard
	the series.

	Suggest use of "git cherry-pick --continue/--skip/--abort"
	so that the message also covers the case where a range of
	commits are being picked.

Helped-by: Phillip Wood [off-list ref]
Hepled-by: Junio C Hamano [off-list ref]

It seems that unlike other people I keep hepling you, whatever that
verb means ;-).

Thanks.

Junio C Hamano [off-list ref] 于2021年8月15日周日 上午4:33写道：

"ZheNing Hu via GitGitGadget" [off-list ref] writes:

quoted

From: ZheNing Hu <redacted>

In the past, git cherry-pick would print such advice when
there was a conflict:
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

In our log messages, we desciribe the current state in the present
tense.

It may be worth mentioning that this is because the program
originally was about picking only one commit and the hint was
inherited from those days.  Or it may not.  I dunno.

Yes, may look at the time, the design is correct.

quoted

But in fact, when we want to cherry-pick multiple commits,
we should not use "git commit" after resolving conflicts, which
will make Git generate some errors. We should recommend users to
use `git cherry-pick --continue`, `git cherry-pick --abort`, just
like git rebase does.

I am not sure "should not" is the right phrase.  Also it does not
help readers to have a vague "generate some errors" than not saying
anything---it leaves readers puzzled with "what errors???"

yes, this error is specifically that if we want pick a series of commits,
after resolving conflicts and use git commit, `.git/sequencer` still exists,
but git cherry-pick has ended (the next step cherry-pick is not performed).
This may be a very strange critical state.

Whether picking a single commit or a series of commits, after
resolving conflicts in the current step, wouldn't

    $ git commit ;# to conclude the resolution
    $ git cherry-pick --continue

do the right thing?

I think you mean that git commit is used to end a single cherry-pick.
But in the face of a series of commits, errors will occur.

quoted

This is the improved advice:

It may be an improved advice, but just omit it and say something
like:

        Suggest use of "git cherry-pick --contiue", so that it would
        also apply to cases where multiple commits are being picked.

The actual message does not have to be reproduced here, as it is in
the source, and it can be seen in the test ;-)

Yes, maybe the commit message should be shorter and more concise.

That would make the proposed log message conform to our norm,
i.e. brief description of what happens with the current system,
followed by description of the perceived problem, followed by
an order to the codebase to become different in a specific way
that solves the problem.

Taken together, perhaps

        "git cherry-pick", upon seeing a conflict, says:

            hint: ...

        as if running "git commit" to conclude the resolution of
        this single step were the end of the story.  This stems from
        the fact that the command originally was to pick a single
        commit and not a range of commits, and the message was
        written back then and has not been adjusted.

        When picking a range of commits and the command stops with a
        conflict in the middle of the range, however, after
        resolving the conflict and (optionally) recording the result
        with "git commit", the user has to run "git cherry-pick
        --continue" to have the rest of the range dealt with,
        "--skip" to drop the current commit, or "--abort" to discard
        the series.

Ok, I understand now, git commit just stopped git cherry-pick by
delete CHERRY_PICK_HEAD in sequencer_post_commit_cleanup().
we can still resume the process with git cherry-pick --continue.

        Suggest use of "git cherry-pick --continue/--skip/--abort"
        so that the message also covers the case where a range of
        commits are being picked.

quoted

Helped-by: Phillip Wood [off-list ref]
Hepled-by: Junio C Hamano [off-list ref]

It seems that unlike other people I keep hepling you, whatever that
verb means ;-).

Ehhh, I seem to have forgotten the correction here.

Thanks.

Thanks.
--
ZheNing Hu