Re: [DISCUSS] Attribution and merging the Elasticsearch client migration

2018-11-16 Thread Otto Fowler
Maybe if we can’t document a concrete solution, we can document or codify a procedure. Should for example the owner of the feature branch always work with the release manager when there are issues? On November 16, 2018 at 10:26:11, Michael Miklavcic ( michael.miklav...@gmail.com) wrote: It's

Re: [DISCUSS] Attribution and merging the Elasticsearch client migration

2018-11-16 Thread Michael Miklavcic
It's a good suggestion, and I've been thinking about how to best handle this. Honestly, the right answer might be to do git rebase on master from the PR branch rather than a merge. That might avoid this situation altogether. Of course, that also comes with all the obligatory warnings about

Re: [DISCUSS] Attribution and merging the Elasticsearch client migration

2018-11-16 Thread Otto Fowler
Maybe this is worth a confluence entry, not as a guide, but just to document what you did. On November 15, 2018 at 19:07:40, Michael Miklavcic ( michael.miklav...@gmail.com) wrote: Ok, this is finally merged! Whew! Here's how I polished up the history at the end. I used other feature branch

Re: [DISCUSS] Attribution and merging the Elasticsearch client migration

2018-11-15 Thread Michael Miklavcic
Ok, this is finally merged! Whew! Here's how I polished up the history at the end. I used other feature branch merges as a guideline around commit messaging. * fcd644ca 2018-11-15 | METRON-1834: Migrate Elasticsearch from TransportClient to new Java REST API (mmiklavc via mmiklavc) (HEAD ->

Re: [DISCUSS] Attribution and merging the Elasticsearch client migration

2018-11-15 Thread Michael Miklavcic
Absolutely, that's part of what I did to validate. This output below also exactly matches the diff I get when I run it from the raw PR branch. git diff master --stat Upgrading.md | 7 +++ dependencies_with_url.csv

Re: [DISCUSS] Attribution and merging the Elasticsearch client migration

2018-11-15 Thread Otto Fowler
Can you diff the trees to be sure? On November 15, 2018 at 17:52:40, Michael Miklavcic ( michael.miklav...@gmail.com) wrote: So amazingly, this still has results in conflicts, but I am able to resolve them manually in a sensible fashion. git merge -X theirs es-rebased CONFLICT (rename/rename):

Re: [DISCUSS] Attribution and merging the Elasticsearch client migration

2018-11-15 Thread Michael Miklavcic
Totally agree Otto. The other concern here is that I believe the automated release scripts need to see the Jira's on the commits. See my latest update as I think I got something workable. On Thu, Nov 15, 2018 at 3:30 PM Otto Fowler wrote: > Proper attribution and the correct code are the most

Re: [DISCUSS] Attribution and merging the Elasticsearch client migration

2018-11-15 Thread Michael Miklavcic
So amazingly, this still has results in conflicts, but I am able to resolve them manually in a sensible fashion. git merge -X theirs es-rebased CONFLICT (rename/rename): Rename

Re: [DISCUSS] Attribution and merging the Elasticsearch client migration

2018-11-15 Thread Otto Fowler
Proper attribution and the correct code are the most important things, not the number of commits. On November 15, 2018 at 16:29:04, Justin Leet (justinjl...@gmail.com) wrote: I took a look at this with Mike a bit, and it seems like it's pretty painful and without a clear way to avoid remerging

Re: [DISCUSS] Attribution and merging the Elasticsearch client migration

2018-11-15 Thread Justin Leet
I took a look at this with Mike a bit, and it seems like it's pretty painful and without a clear way to avoid remerging conflicts. If the latest attempt doesn't work, I'm in favor of getting it in and just getting it down to as few commits as reasonably possible. On Thu, Nov 15, 2018 at 4:12 PM

Re: [DISCUSS] Attribution and merging the Elasticsearch client migration

2018-11-15 Thread Michael Miklavcic
I'm attempting 1 more option, which would be to do a "git merge --strategy-option theirs" after having done the commit wrangling in the PR branch. Will reply back with results. On Thu, Nov 15, 2018 at 2:02 PM Michael Miklavcic < michael.miklav...@gmail.com> wrote: > Yes, definitely. > > On Thu,

Re: [DISCUSS] Attribution and merging the Elasticsearch client migration

2018-11-15 Thread Michael Miklavcic
Yes, definitely. On Thu, Nov 15, 2018 at 2:01 PM Casey Stella wrote: > Can you at least rename your commits to have METRON-1834 prefixing them? > On Thu, Nov 15, 2018 at 15:19 Michael Miklavcic < > michael.miklav...@gmail.com> > wrote: > > > https://github.com/apache/metron/pull/1242 > > > >

Re: [DISCUSS] Attribution and merging the Elasticsearch client migration

2018-11-15 Thread Casey Stella
Can you at least rename your commits to have METRON-1834 prefixing them? On Thu, Nov 15, 2018 at 15:19 Michael Miklavcic wrote: > https://github.com/apache/metron/pull/1242 > > TL;DR > I'd like to discuss the best option to merge METRON-1834 into master. I > want to propose handling this like a