'error: Terminal is dumb, but EDITOR unset - BitBucket Pipeline

I'm using BitBucket Pipelines for the first time to SSH into a development server and perform a git pull origin branch whenever a push is made to the said branch. It's quite simple and everything is going as expected. Problem arises when a merge comes along the pull and a user input is required to commit the merge. I get the following message in the failed build's logs:

 * branch              feature/development -> FETCH_HEAD
d2c27a5f..63d74c8f  feature/development -> origin/feature/development
error: Terminal is dumb, but EDITOR unset
Not committing merge; use 'git commit' to complete the merge.

I would simply like to bypass this user input requirement, commit if necessary and move on.
Here's my build configuration:

image: php:7.1.29

pipelines:
  default:
    - step:
        name: Deploy to dev
        deployment: dev
        # trigger: manual  # Uncomment to make this a manual deployment.
        script:
          - echo "Deploying to dev..."
          - pipe: atlassian/ssh-run:0.2.5
            variables:
              SSH_USER: 'root'
              SERVER: '82.xxx.xx.xx5'
              MODE: 'command'
              COMMAND: 'cd /home/ubuntu/public_html/dev/ && \
                        git pull origin feature/development'
         - echo "Deployed!"

I haven't the faintest how to achieve this. Any hints would be great. TIA!



Solution 1:[1]

Thanks to @phd, I was able to solve this by stopping the commit right after merge, and then supplying my own commit message using -m option.

git pull --no-commit && git commit -m "Merge"

I additionally added strategy -x theirs to ensure that incoming changes are automatically accepted. Added a few more statements to ensure that no local changes are lost, incoming changes are given preference without conflict, and no false positives are reported.
This is what my configuration file looks like right now:

image: php:7.1.29
pipelines:
    default:
        - step:
            name: Deploy to dev
            deployment: dev
            # trigger: manual  # Uncomment to make this a manual deployment.
            script:
               - echo "Deploying to dev..."
               - pipe: atlassian/ssh-run:0.2.5
                 variables:
                   SSH_USER: 'root'
                   SERVER: '82.xxx.xx.xx5'
                   MODE: 'command'
                   COMMAND: 'cd /home/ubuntu/public_html/dev/ && \
                            git add . &&  \
                            git commit -a -m "local files server commit" && \
                            (echo "OK"; exit 0) || (c=$?; echo "NOK"; (exit 0)) && \
                            git pull origin feature/development -X theirs --no-commit && \
                            git commit -m "Merge" && \
                            (echo "OK."; exit 0) || (c=$?; echo "NOK"; (exit 0))'
               - echo "Deployed!"

Solution 2:[2]

By default, when you do a merge, Git tries to invoke an editor so you can edit the commit message and expand on the commit message in a helpful way. If you have not set an editor, Git defaults to vi.

However, in a noninteractive setting, Git knows full well that vi does not work, since you don't have a suitable terminal, so it tries to use the EDITOR environment variable, which should be able to work in a dumb terminal, but it's unset. (It would have used it in preference to vi anyway, had it been set.) That's why you got that message.

If you don't want this behavior, you can set the environment variable GIT_MERGE_AUTOEDIT to no and it will just use the default, which is probably what you want. If you want something different, you can specify it with the -m option, or you can specify a script to edit it in place with the EDITOR environment variable.

Solution 3:[3]

I solved this problem by first running git status in terminal. This command said that all conflicts are fixed and I can run:

git rebase --continue

After I ran the command from above I got this message:

Successfully rebased and updated refs/heads/main.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1
Solution 2 bk2204
Solution 3 Aleksei Mialkin