Re: (unknown)

From: David Greene <greened@obbligato.org>
Date: Dec 18, 2015, 17:35 UTC
Message-ID: <nngr3ij3bj8.fsf@lnx-dag.us.cray.com>
In-Reply-To: <20151216084406.GA3241@pks-pc>

Patrick Steinhardt <ps@pks.im> writes:

Show 17 quoted lines

> On Tue, Dec 15, 2015 at 09:57:50PM -0800, Junio C Hamano wrote:
>> David Greene <greened@obbligato.org> writes:
>> 
>> > - If new option --keep-redundant is specified, invoke cherry-pick with
>> >   --keep-redundant-commits.
>> 
>> This came up in the past several weeks, I think; you would need to
>> disable patch-equivalence based commit filtering if you really want
>> to do a --keep-redundant that is reproducible and/or reliable.
>
> Here are the links to the previous proposal [1] and following
> discussion [2] (see 'ps/rebase-keep-empty') if you are
> interested.
>
> Patrick
>
> [1]: http://thread.gmane.org/gmane.comp.version-control.git/281515[2]: http://thread.gmane.org/gmane.comp.version-control.git/281917

Thanks.  That makes total sense.

I actually would prefer a behavior where cherry-pick would just drop redundant commits rather than stopping and asking the user to reset. The problem is that rebase --preserve-merges seems to force the drop to use cherry-pick and cherry-pick doesn't behave well (from a scripting perspective) in the presence of redundant commits.

As it is, it's difficult to rebase as part of a scripted operation due to this issue.

Any ideas on how to teach cherry-pick to automatically drop such commits?

                           -David