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 > > TL;DR > I'd like to discuss the best option to merge METRON-1834 into master. I > want to propose handling this like a feature branch and merging it as-is. > --- > > I'm sure most folks' initial reaction will be some skepticism akin to "have > you tried turning it off again," as this was my initial reaction as well. > It does not seem like this should be difficult. And I'm hoping that this > may be some esoteric thing on my system, though I believe this is a real > problem. A rather tedious explanation follows of what I've tried and the > problems encountered along the way. What seemed like a really simple > problem instead appears to be a bit much for Git to handle without > requiring redoing merges and another full round of testing. I'd much prefer > to avoid that in this instance. > > This PR is ready to be merged into master. It's recent and very close to > fully up to date in the branch. Latest master merges cleanly. There is an > attribution to Casey Stella for the base point of this PR that I need to > include when getting this into master. When I created my branch, I > collapsed his initial set of commits into a single squashed commit on > master at the time, and I started to work from there. Over time, I made a > number of additional commits and merges from master. Now for the issues. > > Originally, my expectation was that I could have 2 commits - the original > squashed commit from Casey along with all my additional commits (and the > merges with master) right on top. Nice clean history on master. Turns out, > this doesn't work as cleanly as expected because a combination of the > multiple merges and the need to keep the original commit with attribution > to Casey's work. A normal git pull --squash works fine, as expected, but we > lose the base commit, and therefore the requisite attribution. Here are > some other things I've tried, to no avail. > > 1. Git pull --squash after a merge with master. This will squash the > entire tree back to the branch point. No good. > 2. Git rebase -i master. Allows you to cleanly apply changes, but then > it ends up having problems with a clean rebase and shows conflicts. I > expect this is because of the merge history being necessary. > 3. Checking out a branch from the base point squashed commit from Casey, > and attempt to apply my changes on top. Numerous methods for > squashing/rebasing my changes on top applies nicely in the branch. But > then > it once again causes merge conflicts when I attempt to get this onto > master. Things I attempted include: manually copying files, rebasing > all my > commits plus merges on top of the base commit, git merge --squash, > intimidation. > > For one example of the result I'm talking about, this looks "good" but it's > missing a ton of recent commits because they get caught up in the rebase > and get squashed in with my commit. When you attempt to merge this onto > master, it is just plain wrong (see example below with merge conflicts). > * 22c3b3bc 2018-11-15 | METRON-1834: Migrate Elasticsearch from > TransportClient to new Java REST API (mmiklavc via mmiklavc) closes > apache/metron#1242 (HEAD -> stella-es-base2) [mmiklavc] > * 84232e90 2018-10-08 | METRON-1834: Elasticsearch rest client migration > base work starting point for apache/metron#1242 (cstella via mmiklavc) > [cstella] > * 5bfc08c5 2018-10-08 | METRON-1792 Simplify Profile Definitions in > Integration Tests (nickwallen) closes apache/metron#1211 [nickwallen] > > Here's 1 merge conflict (say what??) > CONFLICT (rename/rename): Rename > > "metron-interface/metron-config/src/app/rxjs-operators.ts"->"metron-platform/metron-parsers/src/main/java/org/apache/metron/parsers/ParserRunnerResults.java" > in branch "HEAD" rename > > "metron-interface/metron-config/src/app/rxjs-operators.ts"->"metron-platform/metron-elasticsearch/src/main/java/org/apache/metron/elasticsearch/utils/FieldMapping.java" > in "stella-es-base2" > > If I attempt to use rebase on master instead of merge, it really seems to > mess up the files. Again, another example where I have TODO's that are most > definitely removed by a commit in my branch and also do not exist in > master. I'm not sure what's happening here, but I don't trust it. > { > //TODO: It shouldn't require an assertEventually() here as it should > be synchronous. > // Before merging, please figure out why. > TestUtils.assertEventually(() -> Assert.assertEquals(14, > dao.getColumnMetadata(Collections.singletonList("snort")).size())); > Map<String, FieldType> fieldTypes = > dao.getColumnMetadata(Collections.singletonList("snort")); > <<<<<<< HEAD > Assert.assertEquals(32, fieldTypes.size()); > Assert.assertEquals(FieldType.KEYWORD, > fieldTypes.get("sig_generator")); > ======= > Assert.assertEquals(FieldType.INTEGER, > fieldTypes.get("snort_field")); > >>>>>>> METRON-1834: Elasticsearch rest client migration base work starting > point for apache/metron#1242 (cstella via mmiklavc) >
