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

Question

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!

Portia

git pull is trying to open an editor to ask for a merge commit's message and failed. Try git pull --rebase to avoid merge (but get ready for conflicts). Or run git pull --no-commit && git commit -m "Merge" – Nominee

Thank you so much. I went for --no-commit && git commit -m "Merge" and it worked like a charm. I also went ahead and added -X theirs to ensure incoming changes are accepted automatically. Please turn your comment into an answer so I can accept it. @Nominee :) – Portia

Answer 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!"

Portia

Answer 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.

Kristinakristine

Thanks for the explanation. This helps me understand what the bizarre sounding error message actually means. I went with git pull --no-commit && git commit -m "Merge" as suggested by @phd, but I can see this coming very handy in many situations. – Portia

Answer 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.

Haruspex