nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Ryan <>
Subject Re: Getting lost a bit
Date Mon, 08 Jan 2018 20:46:26 GMT
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

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 <> 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 <> 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 <> 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
>> <
>>>> wrote:
>>>> Hi Devs,
>>>> I'm trying to create a PR for this branch in my fork
>>>> 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.

View raw message