Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:57:33

Felipe Contreras [off-list ref] writes:
You didn't answer, what happens when you run --skip-empty and --allow-empty?
I'll answer to a slightly different question: What should happen?

I think it should error out, because --allow-empty is about
"allowing empty commits to be preserved", and --skip-empty is about
"skipping empty commits (as it says on the package)".

Re: [PATCH v2 3/8] cherry-pick: add --skip-empty option

From: Felipe Contreras <hidden>
Date: 2016-06-15 22:57:33

On Tue, Jun 4, 2013 at 1:30 PM, Junio C Hamano [off-list ref] wrote:
Felipe Contreras [off-list ref] writes:
quoted
You didn't answer, what happens when you run --skip-empty and --allow-empty?
I'll answer to a slightly different question: What should happen?

I think it should error out, because --allow-empty is about
"allowing empty commits to be preserved", and --skip-empty is about
"skipping empty commits (as it says on the package)".
Exactly, so they are related after all. However, --allow-empty says this:

"By default, cherry-picking an empty commit will fail,"

Should we change that too if we introduce --skip-empty?

I don't think so. I think it makes more sense to have a new
--empty-commits=[keep|skip|fail] option, so we don't have to document
how each option affects the other, and what is the default. Or rather;
the option documents that.

In fact, it might make sense to change the default in v2.0 to
--empty-commits=skip. If it makes sense in 'git rebase', why doesn't
it in 'git cherry-pick'?

-- 
Felipe Contreras
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help