Neil Horman <nhorman@xxxxxxxxxxxxx> writes:
> No, you covered all the cases, but I disagree with your assertion that the advice
> is correct (or at least optimal) in any of these cases. If a cherry-pick without
> any options is preformed and the commit is empty (regardless of the reason), the
> advice given is that git commit --allow-empty should be used. With the addition
> of these new options, thats not true any longer. Instead of using git commit
> --allow-empty, you can use git cherry-pick --allow-empty.
Sorry, I am confused. Do you mean that the sequence goes like this (with
concrete examples of command line args)?
$ git cherry-pick nh/empty-rebase
... stops because "git show nh/empty-rebase" is empty
$ git cherry-pick --allow-empty
But that cannot be correct, without --continue [*1*], i.e.
$ git cherry-pick --allow-empty --continue
no? I didn't check, but if the command without --continue in the above
sequence does not error out, I think it is a bug.
I am actually OK with suggesting "git cherry-pick --continue", but then
"cherry-pick --allow-empty" (or "--keep-unnecessary-commits") that punts
and gives the control back to the user should leave enough clue for a
later invocation of itself so that it can realize that the original
invocation was made with "--allow-empty". In other words, I am OK if the
interaction goes like this:
$ git cherry-pick --keep-unnecessary-commits nh/empty-rebase
... stops due to a conflict
$ edit builtin/revert.c
... the result ends up being empty
$ git add -u ;# resolved
$ git cherry-pick --continue
[Side note]
*1* It was an original UI mistake to make the users conclude a "git merge"
that asked the user to help resolving the conflict with "git commit",
which was inherited by "git cherry-pick" and "git revert", especially when
these three commands are merely a special "possibly zero or one stoppage"
case of more general sequencing commands like "am" and "rebase" that can
stop zero or more times to ask the user for help and the way to resume
them is to re-run the same command with "--continue" option (and without
any other arguments), e.g.
$ git am -3 ./+nh.mbox
... stops due to conflict and asks to resolve them
$ edit builtin/revert.c
$ git add builtin/revert.c
$ git am --continue
and also discussed that in the longer-term it would be nice to teach the
oddball commands to honor "--continue". "am" originally took "--resolved"
(and it still does, and it will do so in the future) for the same purpose,
and we taught it and "cherry-pick" and "revert" to honor "--continue".
Probably we should start teaching "merge" to honor it as well to complete
the vision.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html