I should have been more thorough, but yes, of course one must be careful. Which is why I don’t necessarily like GUI merge tools.
NiFi is pretty well structured, so merge problems like you suggest should be less likely unless refactoring of core happens a lot. Git has a pretty smart merge strategy with recursive being the default which allows for method renames. If you get into a situation where two have been working in the same block causing a conflict there may be a problem with what is trying to be achieved. > On 9 Jan 2018, at 05:00, Jeff <[email protected]> wrote: > > Brett, > > You don't want to necessarily delete the other side and just keep the > section you've modified... There may be changes that were made to that > code that you'll want to add to your own changes. A simple example would > be that a new method call was added in the section that you've modified, > which caused the conflict. Deleting that other side of the diff would > remove that method call, and undo someone else's work. We need to be > careful when resolving conflicts to make sure the final commit is a proper > merging of the commits (yours and and any from the git repo) that were made > since the commit hash from which you were making your changes. > > - Jeff > >> On Mon, Jan 8, 2018 at 1:58 AM Brett Ryan <[email protected]> wrote: >> >> I must be an odd one, I’m more comfortable resolving conflicts from the >> cli ;) >> >> The simplest way is the CSV resolution strategy. Edit each file looking >> for <<< —- >>> blocks where conflicts are presented. Keep the section you >> want deleting the other side, then git add the file. Do for all conflicts >> then git commit. >> >> Fetch often to try and keep your base aligned in order to keep conflicts >> as small as possible. >> >>> On 8 Jan 2018, at 17:03, James Wing <[email protected]> wrote: >>> >>> Mike, >>> >>> I believe you will want to rebase your branch on the latest master before >>> you submit your PR. First, update your master branch if you have not >>> already done so, with commands like the following: >>> >>> git checkout master >>> git fetch origin >>> git merge origin/master >>> >>> Second, rebase your feature branch so that your commits are relative to >> the >>> latest master: >>> >>> git checkout NIFI-4731 >>> git rebase master >>> >>> Given the recent changes in the GCP bundle, you may have some conflicts >> to >>> resolve. A GUI tool like IntelliJ can be very handy for resolving git >>> conflicts if you are not familiar with the command-line git resolution >>> process (almost nobody is). >>> >>> If that does not work for you, an alternative would be to create a new >>> branch from the latest master, then manually copy/paste your changes to >>> make a more concise commit. >>> >>> Thanks, >>> >>> James >>> >>> On Sun, Jan 7, 2018 at 7:16 PM, Mikhail Sosonkin >> <[email protected] >>>> wrote: >>> >>>> Hi Devs, >>>> >>>> I'm trying to create a PR for this branch in my fork >>>> https://github.com/nologic/nifi/tree/NIFI-4731. I see that master has >>>> moved >>>> on to 1.5.0 but I'd like to have the processor built for 1.4 and later. >>>> It's the version we're using. However, I don't see an origin/1.4.0 >> based on >>>> the instructions from the contributor guide. How do I go about this? >> Please >>>> give simple instructions, I'm not exactly a git master :) >>>> >>>> Thanks, >>>> Mike. >>>> >>>> -- >>>> This email may contain material that is confidential for the sole use of >>>> the intended recipient(s). Any review, reliance or distribution or >>>> disclosure by others without express permission is strictly >> prohibited. If >>>> you are not the intended recipient, please contact the sender and delete >>>> all copies of this message. >>
