GitLab

Created by: pkozelka

In a repository with quite a long history, I recently added the .gitattributes file with single line in it:

* text=auto

This led to a strange behavior of all git clients once they pulled:

• users observed modified files that they did not touch
• even fresh clone reported modifications in status
• there was no way to revert those magical-changes
• they had to be committed with a regular commit in the end

This is probably an issue in git itself; but I think that gitlab should be able to cope with that. The magical changes appeared on files that were committed with CRLF endlines.

What happened on Gitlab UI

First, let me name the two important commits.

• commit A is the one introducing .gitattributes file
• commit B is the one holding magical changes

When I looked at a merge-request that branched off a commit after A, the UI control which normally indicates if the request can be merged was rotating, forever - due to unhandled HTTP 500 from the server

What happened on Gitlab host

• its sattelite repository suffered the same problem as every client - magical changes that prevented the local merge attempt, used in automerge check
• failure to check led to returning HTTP 500 and reporting failure to delete the develop branch which is quite confusing

log fragment:

Processing by Projects::MergeRequestsController#automerge_check as JSON
  Parameters: {"project_id"=>"mygroup/myrepo", "id"=>"154"}
Started GET "/api/v3/users/6.json?private_token=UXXXXKmcYF6KUX-Qziu8" for 127.0.0.1 at 2015-06-10 08:48:57 +0200
Completed 500 Internal Server Error in 327ms

Grit::Git::CommandFailed (Command failed [1]: /opt/gitlab/embedded/bin/git --git-dir=/GITrepo/gitlab-satellites/mygroup/myrepo/.git --work-tree=/GITrepo/gitlab-satellites/mygroup/myrepo branch -D develop

error: Cannot delete the branch 'develop' which you are currently on.
):
  lib/gitlab/satellite/satellite.rb:107:in `block in delete_heads!'
  lib/gitlab/satellite/satellite.rb:107:in `each'
  lib/gitlab/satellite/satellite.rb:107:in `delete_heads!'
  lib/gitlab/satellite/satellite.rb:23:in `clear_and_update!'
  lib/gitlab/satellite/action.rb:40:in `prepare_satellite!'
  lib/gitlab/satellite/merge_action.rb:15:in `block in can_be_merged?'
  lib/gitlab/satellite/action.rb:24:in `block (2 levels) in in_locked_and_timed_satellite'
  lib/gitlab/satellite/satellite.rb:56:in `block in lock'
  lib/gitlab/satellite/satellite.rb:53:in `open'
  lib/gitlab/satellite/satellite.rb:53:in `lock'
  lib/gitlab/satellite/action.rb:23:in `block in in_locked_and_timed_satellite'
  lib/gitlab/satellite/action.rb:22:in `in_locked_and_timed_satellite'
  lib/gitlab/satellite/merge_action.rb:14:in `can_be_merged?'
  app/models/merge_request.rb:176:in `check_if_can_be_merged'
  app/controllers/projects/merge_requests_controller.rb:106:in `automerge_check'

Workarround

on clients:

• first, create and push commit B
• rebase all active branches that originate between commits A and B so that they contain either both or none of commits A and B
• alternatively, merge the branch with commit B

on Gitlab host:

cd /GITrepo/gitlab-satellites/mygroup/myrepo
git commit -am 'Dummy Commit Fixing Newlines'
git pull -r
git status

Problems worth solving

1. sure, git should handle this situation better - I hope I'll find time to report this to git devs
2. gitlab ui should handle all possible errors coming from the server, even HTTP 500; when a shell interaction is behind servicing the request, perhaps all kinds of problems can be expected
3. gitlab server should never return HTTP 500; in cases like this, I think it should report something like automerge check failed or something
4. gitlab server should recover from this situation by itself, at least by re-creating the satellite repo after failure

If I can suggest, solving these in reverse order will make gitlab much more robust.