Ok, I went ahead and changed it in gerrit. Let me know if you have any
problems with it.
On Mon, Dec 11, 2017 at 11:58 AM, Philip Zeyliger
wrote:
> Seems like it's the right thing to do.
>
> On Mon, Dec 11, 2017 at 11:43 AM, Tim Armstrong
> wrote:
>
> > We recently had a bad merge that was allo
Seems like it's the right thing to do.
On Mon, Dec 11, 2017 at 11:43 AM, Tim Armstrong
wrote:
> We recently had a bad merge that was allowed by the cherry-pick merge
> strategy merging a simple without its ancestor (since they didn't change
> any nearby lines):
> https://lists.apache.org/thread.
OK, sgtm
On Mon, Dec 11, 2017 at 1:07 PM, Tim Armstrong
wrote:
> AFAIK there isn't a version of cherry-pick like that (which only
> cherry-picks commits if their parent is in the target branch).
>
> "Rebase always" should include the same footer as "cherry pick", according
> to that link you pro
AFAIK there isn't a version of cherry-pick like that (which only
cherry-picks commits if their parent is in the target branch).
"Rebase always" should include the same footer as "cherry pick", according
to that link you provided. They summarise it as "Rebase Always can be
considered similar to Che
Is there a merge strategy that just doesn't allow commit chains longer than
1?
Also
https://gerrit-review.googlesource.com/Documentation/project-configuration.html
says
"When cherry picking a change, Gerrit automatically appends onto the end of
the commit message a short summary of the change’s a
We recently had a bad merge that was allowed by the cherry-pick merge
strategy merging a simple without its ancestor (since they didn't change
any nearby lines):
https://lists.apache.org/thread.html/ee81ee3e396a9a7b1214d92d713a2d28f2f1f7058184504ebc399170@%3Cdev.impala.apache.org%3E
It looks like
