hg: amber/amber: Automatic merge with default

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Tue Oct 15 07:57:28 UTC 2019


Hi Chris,
was thinking the same, but the changeset has been picked up by 3-4 
different branches already, so this time looks more complex.

Wouldn't that invalidate the process somewhat? (the other times we did 
it, there was no other change "on top" of the bad one)

Maurizio

On 15/10/2019 08:37, Chris Hegarty wrote:
> Srikanth,
>
> There may be a simple fix?  When then next changeset comes into the default branch ( from jdk/jdk ), then it will create two heads in the default branch. Allow that changeset to propagate to the other downstream branches ( which will happen automatically ). Then just “closed” the bad sub-branch.
>
> I can try this locally to see how it works.
>
> -Chris.
>
>> On 15 Oct 2019, at 06:16, Srikanth <srikanth.adayapalam at oracle.com> wrote:
>>
>> Folks,
>>
>> My sincere apologies - some strip operations I had to do on my local clone automatically resulted in a change of branch and I seem to have inadvertently pushed what was meant to go into the branch "local-methods" into default by mistake.
>>
>> I see that automatic merges are pulling these changes into other branches in amber resulting in a cascade :-(
>>
>> I am figuring how what is the recommended way to reverse this badness. In the meantime it may be a good idea to hold any pushes to amber repo until this mess is cleared.
>>
>> Very very sorry about this.
>> Thanks
>> Srikanth
>>
>> On 15/10/19 10:41 AM, maurizio.cimadamore at oracle.com wrote:
>>> Changeset: 7668209a3b1a
>>> Author:    mcimadamore
>>> Date:      2019-10-15 05:11 +0000
>>> URL:       https://hg.openjdk.java.net/amber/amber/rev/7668209a3b1a
>>>
>>> Automatic merge with default
>>>
>>>


More information about the amber-dev mailing list