I'm not sure what value there is in preserving this accidental merge in history, but all options proposed seem fine to me. We should resolve this (or at least unblock other dev work) quickly though.
On Tue, Mar 6, 2018 at 3:16 PM Kenneth Knowles <k...@google.com> wrote: > My own vote is for leaving the history immutable, which is the case for > the full rollback or leaving it there disabled. > > > On Tue, Mar 6, 2018 at 3:01 PM Thomas Weise <t...@apache.org> wrote: > >> +1 for (1), assuming it is straightforward to exclude from the build and >> eventually will end up in master anyways. >> >> On Tue, Mar 6, 2018 at 2:59 PM, Robert Bradshaw <rober...@google.com> >> wrote: >> >>> I would opt for (2), but I'm not sure who has permissions to do that. It >>> should be easy to re-merge the couple of things that have gone in since >>> then. >>> >>> >>> On Tue, Mar 6, 2018 at 2:43 PM Kenneth Knowles <k...@google.com> wrote: >>> >>>> Hi all, >>>> >>>> You may have noticed that our tests are red. A pull request that was >>>> meant for the Go SDK branch accidentally got merged onto the master branch. >>>> Things have been merged to master since then. >>>> >>>> I've opened a revert at https://github.com/apache/beam/pull/4808 >>>> >>>> The next time there is a master to go-sdk merge it will need to be >>>> re-reverted. >>>> >>>> Two other options are (1) leave it there and disable it in whatever way >>>> and (2) rebase dropping the commit and force push master (breaks all >>>> checkouts that are past it). >>>> >>>> Kenn >>>> >>> >>
