Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH] cherry-pick: No advice to commit if --no-commit

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:53:07

Jonathan Nieder [off-list ref] writes:
quoted
+	if (show_hint) {
 		advise(_("after resolving the conflicts, mark the corrected paths\n"
+			 "with 'git add <paths>' or 'git rm <paths>'"));
+		if (!opts->no_commit)
+			advise(_( "and commit the result with 'git commit'"));
"cherry-pick --no-commit" was not about to commit, but the user might
have been.  I think the hint is intended to convey that authorship
will be correctly preserved if the user continues with "git commit"
and no special -c option is necessary.
Actually, an often used but perhaps neglected use case of "cherry-pick --no-commit"
is to use it as a substitute for

	git show $that_commit | git apply [--index]

to lift the change from $that_commit and incorporate it into your
unrelated (from the point of view of the author of $that_commit) work.
The user would be doing "edit $this_file" and "edit $that_file" before or
after the "show | apply" aka "cherry-pick --no-commit", and it is merely
a type-saver, not having to re-type the change $that_commit introduced
relative to its parent.

So in that context, I can understand the suggestion to commit is at best
annoying ("I am still working on the current change. Why do you talk about
committing?") and at worst alarming and misleading ("Oh, am I to lose some
change if I do not commit right now?").
A smaller detail: splitting the message into two like this gives
translators less control over how to phrase the message and where to
wrap lines.  Luckily that is easy to fix with

	if (opts->no_commit)
		advise(...);
	else
		advise(...);
Yes, this pattern must be followed in the reroll.

Thanks for a review and comment.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help