[JENKINS-50401] Checkout resolution misbehaves with local branch and forward slashes

If the git plugin uses a local branch which is named the same as the remote and contains a forward slash, it will cause the checkout command to not update to the latest commit. Since using branches with / is common and local branch might be necessary, this should be fixed or at least produce a warning.

To test: Create the following pipeline:

node {

  stage ('hello') {

    dir ('foo') {

      checkout([$class: 'GitSCM', branches: [[name: "foo/bar"]], extensions: [[$class: 'LocalBranch', localBranch: 'foo/bar']], userRemoteConfigs: [[credentialsId: '...', url: "..."]]])

    }

  }

}

And follow these steps:

1. Push branch foo/bar


2. Run pipeline


3. Push branch foo/bar with new versions


4. Re-run pipeline in same folder

The output should have the following contents:

 > git.exe fetch --tags --progress ssh://xxxx +refs/heads/*:refs/remotes/origin/*

 > git.exe rev-parse "foo/bar^{commit}" # timeout=10

 > git.exe rev-parse "refs/remotes/origin/foo/bar^{commit}" # timeout=10

Multiple candidate revisions

Checking out Revision 7bbd0143e31f1280e032cf350cf9f466642d1d65 (foo/bar)

The 7bbd014 is the older commit however, since the local branch takes precedence over the remote one.

Workarounds:

• Name the local branch differently from the remote branch


• Specify the fully quialified branch name (remotes/origin/${branch}) in the checkout command

---
Originally reported by shauser, imported from: Checkout resolution misbehaves with local branch and forward slashes

• status: Open
  
• priority: Minor
  
• component(s): git-plugin
  
• resolution: Unresolved
  
• votes: 0
  
• watchers: 4
  
• imported: 2025-12-02
  

Raw content of original issue

If the git plugin uses a local branch which is named the same as the remote and contains a forward slash, it will cause the checkout command to not update to the latest commit. Since using branches with / is common and local branch might be necessary, this should be fixed or at least produce a warning.


To test: Create the following pipeline:



node {

  stage ('hello') {

    dir ('foo') {

      checkout([$class: 'GitSCM', branches: [[name: "foo/bar"]], extensions: [[$class: 'LocalBranch', localBranch: 'foo/bar']], userRemoteConfigs: [[credentialsId: '...', url: "..."]]])

    }

  }

}



And follow these steps:



	
Push branch foo/bar

	
Run pipeline

	
Push branch foo/bar with new versions

	
Re-run pipeline in same folder



The output should have the following contents:



 > git.exe fetch --tags --progress ssh://xxxx +refs/heads/*:refs/remotes/origin/*

 > git.exe rev-parse "foo/bar^{commit}" # timeout=10

 > git.exe rev-parse "refs/remotes/origin/foo/bar^{commit}" # timeout=10

Multiple candidate revisions

Checking out Revision 7bbd0143e31f1280e032cf350cf9f466642d1d65 (foo/bar)





The 7bbd014 is the older commit however, since the local branch takes precedence over the remote one.


Workarounds:



	
Name the local branch differently from the remote branch

	
Specify the fully quialified branch name (remotes/origin/${branch}) in the checkout command

• environment: Jenkins 2.107.1, git-plugin 2.7.1