We have been using Spring Cloud Config [1.0.2.RELEASE] for some time now and its working out well for us. Thank you!

Today, we noticed an error during the start up of the config server with the following stack trace: Restarting the config server resolved the issue -- but was curious to know how this could have happened. Multiple apps rely on the same config server to start up and was wondering if it could be due to some concurrency issue.

Caused by: org.eclipse.jgit.api.errors.CheckoutConflictException: Checkout conflict with files: 
application.properties
....
....
    at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:265) ~[org.eclipse.jgit-3.5.3.201412180710-r.jar!/:3.5.3.201412180710-r]
    at org.springframework.cloud.config.server.JGitEnvironmentRepository.checkout(JGitEnvironmentRepository.java:129) ~[spring-cloud-config-server-1.0.1.RELEASE.jar!/:1.0.1.RELEASE]
    at org.springframework.cloud.config.server.JGitEnvironmentRepository.loadEnvironment(JGitEnvironmentRepository.java:110) ~[spring-cloud-config-server-1.0.1.RELEASE.jar!/:1.0.1.RELEASE]
    at org.springframework.cloud.config.server.JGitEnvironmentRepository.findOne(JGitEnvironmentRepository.java:80) ~[spring-cloud-config-server-1.0.1.RELEASE.jar!/:1.0.1.RELEASE]
    ... 70 common frames omitted
Caused by: org.eclipse.jgit.errors.CheckoutConflictException: Checkout conflict with files: 
application.properties
...
...
    at org.eclipse.jgit.dircache.DirCacheCheckout.doCheckout(DirCacheCheckout.java:416) ~[org.eclipse.jgit-3.5.3.201412180710-r.jar!/:3.5.3.201412180710-r]
    at org.eclipse.jgit.dircache.DirCacheCheckout.checkout(DirCacheCheckout.java:397) ~[org.eclipse.jgit-3.5.3.201412180710-r.jar!/:3.5.3.201412180710-r]
    at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:261) ~[org.eclipse.jgit-3.5.3.201412180710-r.jar!/:3.5.3.201412180710-r]
    ... 73 common frames omitted

Comment From: otrosien

I think this happens when you force-push into your config-repo.

Comment From: dsyer

Yes, either that or someone edited the working copy on the server?

Comment From: vishalmanohar

Hmm. Doesn't look like we did either.

Comment From: dsyer

Can you be a bit more specific about steps to reproduce then?

Comment From: vishalmanohar

@dsyer It happened only once over the last few weeks that we have been using the config server and we didn't do anything differently when this happened.

The set up is straight forward - multiple apps that listen to the config server -- which all start together during server start up. Will update if this happens again.

Comment From: blancqua

Same occurred here, indeed after a force push. We do not consider force pushes as a bad practice (squash commits on a separate dev branch in the git repo). We did a force push an a branch which was not used in our production environment at all, however it caused the config server to fail. We consider this a bug. Is there any way to restrict the config server which branches to check out to avoid this issue for us in production?

Caused by: org.eclipse.jgit.api.errors.CheckoutConflictException: Checkout conflict with files:
application-cd.yml
application-docker.yml
        at org.eclipse.jgit.api.CheckoutCommand.call(CheckoutCommand.java:265) ~[org.eclipse.jgit-3.5.3.201412180710-r.jar!/:3.5.3.201412180710-r]
        at org.springframework.cloud.config.server.environment.JGitEnvironmentRepository.checkout(JGitEnvironmentRepository.java:204) ~[spring-cloud-config-server-1.1.2.RELEASE.jar!/:1.1.2.RELEASE]
        at org.springframework.cloud.config.server.environment.JGitEnvironmentRepository.refresh(JGitEnvironmentRepository.java:148) ~[spring-cloud-config-server-1.1.2.RELEASE.jar!/:1.1.2.RELEASE]
        at org.springframework.cloud.config.server.environment.JGitEnvironmentRepository.getLocations(JGitEnvironmentRepository.java:121) ~[spring-cloud-config-server-1.1.2.RELEASE.jar!/:1.1.2.RELEASE]
        at org.springframework.cloud.config.server.environment.MultipleJGitEnvironmentRepository.getLocations(MultipleJGitEnvironmentRepository.java:111) ~[spring-cloud-config-server-1.1.2.RELEASE.jar!/:1.1.2.RELEASE]
        at org.springframework.cloud.config.server.environment.AbstractScmEnvironmentRepository.findOne(AbstractScmEnvironmentRepository.java:40) ~[spring-cloud-config-server-1.1.2.RELEASE.jar!/:1.1.2.RELEASE]
        at org.springframework.cloud.config.server.environment.MultipleJGitEnvironmentRepository.findOne(MultipleJGitEnvironmentRepository.java:146) ~[spring-cloud-config-server-1.1.2.RELEASE.jar!/:1.1.2.RELEASE]
        at org.springframework.cloud.config.server.environment.EnvironmentEncryptorEnvironmentRepository.findOne(EnvironmentEncryptorEnvironmentRepository.java:53) ~[spring-cloud-config-server-1.1.2.RELEASE.jar!/:1.1.2.RELEASE]
        at org.springframework.cloud.config.server.environment.EnvironmentController.labelled(EnvironmentController.java:112) ~[spring-cloud-config-server-1.1.2.RELEASE.jar!/:1.1.2.RELEASE]
        at sun.reflect.GeneratedMethodAccessor114.invoke(Unknown Source) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_91]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_91]
        at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221) ~[spring-web-4.3.2.RELEASE.jar!/:4.3.2.RELEASE]
        at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136) ~[spring-web-4.3.2.RELEASE.jar!/:4.3.2.RELEASE]
        at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:114) ~[spring-webmvc-4.3.2.RELEASE.jar!/:4.3.2.RELEASE]
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827) ~[spring-webmvc-4.3.2.RELEASE.jar!/:4.3.2.RELEASE]
        at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738) ~[spring-webmvc-4.3.2.RELEASE.jar!/:4.3.2.RELEASE]
        at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85) ~[spring-webmvc-4.3.2.RELEASE.jar!/:4.3.2.RELEASE]
        at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:963) ~[spring-webmvc-4.3.2.RELEASE.jar!/:4.3.2.RELEASE]
        at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:897) ~[spring-webmvc-4.3.2.RELEASE.jar!/:4.3.2.RELEASE]
        at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970) ~[spring-webmvc-4.3.2.RELEASE.jar!/:4.3.2.RELEASE]
        ... 56 more
Caused by: org.eclipse.jgit.errors.CheckoutConflictException: Checkout conflict with files:
application-cd.yml

Comment From: tagae

This happened to me upon a forced push. Is there a way the config server can be configured to do a git reset --hard <label> and git clean -fd upon each refresh of the repo? or something along these lines that would avoid the kind of error described above?

Comment From: dsyer

473 adds a flag `spring.cloud.config.server.git.forcePull`. Did you try that?

A lot of dirty repo problems have been reported to be caused by temp file cleaners in production servers (BSD and RHEL I think in particular). You can side step those by using an explicit spring.cloud.config.server.git.basedir.

Comment From: spring-projects-issues

Closing due to age of the question. If you would like us to look at this issue, please comment and we will look at re-opening the issue.

Comment From: marecica2

Any thought on this we are experiencing this as well whe have explicitly configured baseDir outside of /tmp

spring:
  cloud:
    config:
      server:
        git:
          uri: ${GIT_ENDPOINT:https://our-bitbucket/scm/ic/configuration.git}
          username: ${GIT_USER}
          password: ${GIT_PWD}
          refresh-rate: 10
          force-pull: true # we try to force pull  but it doesnt seems to work
          clone-on-start: true 
          default-label: ${DEFAULT_BRANCH:develop}
          delete-untracked-branches: true
          basedir: /git-repo   # absolute path to fs root directory with 777

We dont squash commits or rewrite history neither force push on those target branches where the issue occurs. We use bitbucket and -no-ff merge strategy to merge PRs The spring cloud config server is running in docker image in k8s cluster

Should'nt force-pull avoid this kind of issues anyway?

Spring Cloud Config Spring Config Server failed to start up with git conflict error

473 adds a flag spring.cloud.config.server.git.forcePull. Did you try that?

473 adds a flag `spring.cloud.config.server.git.forcePull`. Did you try that?