-
Bug
-
Resolution: Won't Fix
-
Minor
-
Jenkins 2.35 running on Windows w/ git 2.7
Git-client 2.2.0 / Git Plugin 3.0.1 / GitLab plugin 1.4.4
We use feature branches on a git repository running on a GitLab server; with a webhook to poll jenkins on the git repository. We've several branches:
master
develop
feature/A
feature/B
...
A user from doc team added some feature branches named with a capital letter:
Feature/C
Feature/D
...
From this point, our job configured to build our application on feature branches commit detection with pattern */feature/${FEATURE_BRANCH} always built the same branch feature/A even if changes were made in feature/B etc.
I reproduced the problem on a fresh git repository, reproducing a quick life of the repository; before the addition of Feature/C; everything ran fine. With the Addition of Feature/C; the problem occurred.
When both feature and Feature branches were present; the polling was triggered by GitLab but the detection of the origin branch of the commit does not work on jenkins.
I found as workaround to change my pattern from */feature/${FEATURE_BRANCH} to */*eature/${FEATURE_BRANCH} but I was expecting that even if feature branches were added starting with Feature instead of feature; the process would detect and get the commit on the right branch.
Some logs:
Example of bad detection (last commit was not on the feature/sync branch):
Cloning the remote Git repository
Cloning repository git@git1.eu.lcom:mobilite/CollectionAndroid.git
> C:\Progs\Git\bin\git.exe init c:\CI\workspace\LCatalog-android-feature-build # timeout=10
Fetching upstream changes from git@git.eu.lcom:mobilite/CollectionAndroid.git
> C:\Progs\Git\bin\git.exe --version # timeout=10
> C:\Progs\Git\bin\git.exe -c core.askpass=true fetch --tags --progress git@git1.eu.lcom:mobilite/CollectionAndroid.git +refs/heads/:refs/remotes/origin/
> C:\Progs\Git\bin\git.exe config remote.origin.url git@git1.eu.lcom:mobilite/CollectionAndroid.git # timeout=10
> C:\Progs\Git\bin\git.exe config --add remote.origin.fetch +refs/heads/:refs/remotes/origin/ # timeout=10
> C:\Progs\Git\bin\git.exe config remote.origin.url git@git1.eu.lcom:mobilite/CollectionAndroid.git # timeout=10
Pruning obsolete local branches
Fetching upstream changes from git@git1.eu.lcom:mobilite/CollectionAndroid.git
> C:\Progs\Git\bin\git.exe -c core.askpass=true fetch --tags --progress git@srdspgit1.eu.lcom:mobilite/CollectionAndroid.git +refs/heads/:refs/remotes/origin/ --prune
Seen branch in repository origin/Feature/FicheC
Seen branch in repository origin/Feature/Wording_13-01
Seen branch in repository origin/Feature/Wording_15-12
Seen branch in repository origin/Feature/account
Seen branch in repository origin/Feature/change-decsription-button
Seen branch in repository origin/Feature/change-tracking-ajustements
Seen branch in repository origin/Feature/change_tracking
Seen branch in repository origin/Feature/login
Seen branch in repository origin/Feature/remove-guava
Seen branch in repository origin/Feature/sync
Seen branch in repository origin/develop
Seen branch in repository origin/master
Seen branch in repository origin/masterv5r1
Seen 13 remote branches
Checking out Revision 5e63c5c7488bcdab1632467cc61bbae2dc67eb87 (refs/remotes/origin/feature/sync)
> C:\Progs\Git\bin\git.exe config core.sparsecheckout # timeout=10
> C:\Progs\Git\bin\git.exe checkout -f 5e63c5c7488bcdab1632467cc61bbae2dc67eb87
> C:\Progs\Git\bin\git.exe rev-list 5e63c5c7488bcdab1632467cc61bbae2dc67eb87 # timeout=10
No emails were triggered.
[EnvInject] - Executing scripts and injecting environment variables after the SCM step.
[EnvInject] - Injecting as environment variables the properties content
JAVA_HOME=C:\Progs\jdk-1.8.0_60
And the list of branches seen by Git command line; note that all feature branches are named with lower case names instead of the two Feature/Wording* branches:
$ git branch --list --all
- develop
remotes/origin/HEAD -> origin/develop
remotes/origin/develop
remotes/origin/feature/FicheCad
remotes/origin/feature/account
remotes/origin/feature/advanced
remotes/origin/feature/change-decsription-button
remotes/origin/feature/change-tracking-ajustements
remotes/origin/feature/change_tracking
remotes/origin/feature/login
remotes/origin/feature/remove-guava
remotes/origin/feature/sync
remotes/origin/Feature/Wording_11-01
remotes/origin/Feature/Wording_15-12
remotes/origin/master
remotes/origin/masterv5r1
- is related to
-
-
- Closed
-
[JENKINS-41506] Polling doesn't detect changes in feature branches (case sensitivity)
| Description |
Original:
We use feature branches on a git repository running on a GitLab server; with a webhook to poll jenkins on the git repository. We've several branches: master develop feature/A feature/B ... A user from doc team added some feature branches named with a capital letter: Feature/C Feature/D ... From this point, our job configured to build our application on feature branches commit detection with pattern */feature/${FEATURE_BRANCH} always built the same branch feature/A even if changes were made in feature/B etc. I reproduced the problem on a fresh git repository, reproducing a quick life of the repository; before the addition of Feature/C; everything ran fine. With the Addition of Feature/C; the problem occurred. When both feature and Feature branches were present; the polling was triggered by GitLab but the detection of the origin of the commit does not work on jenkins. I found as workaround to change my pattern from */feature/${FEATURE_BRANCH} to */*eature/${FEATURE_BRANCH} but I was expecting that even if feature branches were added starting with Feature instead of feature; the process would detect and get the commit on the right branch. |
New:
We use feature branches on a git repository running on a GitLab server; with a webhook to poll jenkins on the git repository. We've several branches: master develop feature/A feature/B ... A user from doc team added some feature branches named with a capital letter: Feature/C Feature/D ... From this point, our job configured to build our application on feature branches commit detection with pattern */feature/\${FEATURE_BRANCH} always built the same branch feature/A even if changes were made in feature/B etc. I reproduced the problem on a fresh git repository, reproducing a quick life of the repository; before the addition of Feature/C; everything ran fine. With the Addition of Feature/C; the problem occurred. When both feature and Feature branches were present; the polling was triggered by GitLab but the detection of the origin of the commit does not work on jenkins. I found as workaround to change my pattern from */feature/\${FEATURE_BRANCH} to */*eature/\${FEATURE_BRANCH} but I was expecting that even if feature branches were added starting with Feature instead of feature; the process would detect and get the commit on the right branch. |
| Description |
Original:
We use feature branches on a git repository running on a GitLab server; with a webhook to poll jenkins on the git repository. We've several branches: master develop feature/A feature/B ... A user from doc team added some feature branches named with a capital letter: Feature/C Feature/D ... From this point, our job configured to build our application on feature branches commit detection with pattern */feature/\${FEATURE_BRANCH} always built the same branch feature/A even if changes were made in feature/B etc. I reproduced the problem on a fresh git repository, reproducing a quick life of the repository; before the addition of Feature/C; everything ran fine. With the Addition of Feature/C; the problem occurred. When both feature and Feature branches were present; the polling was triggered by GitLab but the detection of the origin of the commit does not work on jenkins. I found as workaround to change my pattern from */feature/\${FEATURE_BRANCH} to */*eature/\${FEATURE_BRANCH} but I was expecting that even if feature branches were added starting with Feature instead of feature; the process would detect and get the commit on the right branch. |
New:
We use feature branches on a git repository running on a GitLab server; with a webhook to poll jenkins on the git repository. We've several branches: master develop feature/A feature/B ... A user from doc team added some feature branches named with a capital letter: Feature/C Feature/D ... From this point, our job configured to build our application on feature branches commit detection with pattern */feature/${FEATURE_BRANCH} always built the same branch feature/A even if changes were made in feature/B etc. I reproduced the problem on a fresh git repository, reproducing a quick life of the repository; before the addition of Feature/C; everything ran fine. With the Addition of Feature/C; the problem occurred. When both feature and Feature branches were present; the polling was triggered by GitLab but the detection of the origin of the commit does not work on jenkins. I found as workaround to change my pattern from */feature/${FEATURE_BRANCH} to */*eature/${FEATURE_BRANCH} but I was expecting that even if feature branches were added starting with Feature instead of feature; the process would detect and get the commit on the right branch. |
| Comment |
[ Example of bad detection (last commit was not on the feature/sync branch): Cloning the remote Git repository Cloning repository git@git1.eu.lcom:mobilite/CollectionAndroid.git > C:\Progs\Git\bin\git.exe init c:\CI\workspace\LCatalog-android-feature-build # timeout=10 Fetching upstream changes from git@git.eu.lcom:mobilite/CollectionAndroid.git > C:\Progs\Git\bin\git.exe --version # timeout=10 > C:\Progs\Git\bin\git.exe -c core.askpass=true fetch --tags --progress git@git1.eu.lcom:mobilite/CollectionAndroid.git +refs/heads/*:refs/remotes/origin/* > C:\Progs\Git\bin\git.exe config remote.origin.url git@git1.eu.lcom:mobilite/CollectionAndroid.git # timeout=10 > C:\Progs\Git\bin\git.exe config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 > C:\Progs\Git\bin\git.exe config remote.origin.url git@git1.eu.lcom:mobilite/CollectionAndroid.git # timeout=10 Pruning obsolete local branches Fetching upstream changes from git@git1.eu.lcom:mobilite/CollectionAndroid.git > C:\Progs\Git\bin\git.exe -c core.askpass=true fetch --tags --progress git@srdspgit1.eu.lcom:mobilite/CollectionAndroid.git +refs/heads/*:refs/remotes/origin/* --prune Seen branch in repository origin/Feature/FicheC Seen branch in repository origin/Feature/Wording_13-01 Seen branch in repository origin/Feature/Wording_15-12 Seen branch in repository origin/Feature/account Seen branch in repository origin/Feature/change-decsription-button Seen branch in repository origin/Feature/change-tracking-ajustements Seen branch in repository origin/Feature/change_tracking Seen branch in repository origin/Feature/login Seen branch in repository origin/Feature/remove-guava Seen branch in repository origin/Feature/sync Seen branch in repository origin/develop Seen branch in repository origin/master Seen branch in repository origin/masterv5r1 Seen 13 remote branches Checking out Revision 5e63c5c7488bcdab1632467cc61bbae2dc67eb87 (refs/remotes/origin/feature/sync) > C:\Progs\Git\bin\git.exe config core.sparsecheckout # timeout=10 > C:\Progs\Git\bin\git.exe checkout -f 5e63c5c7488bcdab1632467cc61bbae2dc67eb87 > C:\Progs\Git\bin\git.exe rev-list 5e63c5c7488bcdab1632467cc61bbae2dc67eb87 # timeout=10 No emails were triggered. [EnvInject] - Executing scripts and injecting environment variables after the SCM step. [EnvInject] - Injecting as environment variables the properties content JAVA_HOME=C:\Progs\jdk-1.8.0_60 And the list of branches seen by Git command line; note that all feature branches are named with lower case names instead of the two Feature/Wording* branches: $ git branch --list --all * develop Feature/Wording_11-01 Feature/Wording_15-12 remotes/origin/HEAD -> origin/develop remotes/origin/develop remotes/origin/feature/FicheCad remotes/origin/feature/account remotes/origin/feature/advanced remotes/origin/feature/change-decsription-button remotes/origin/feature/change-tracking-ajustements remotes/origin/feature/change_tracking remotes/origin/feature/login remotes/origin/feature/remove-guava remotes/origin/feature/sync remotes/origin/master remotes/origin/masterv5r1 ] |
| Description |
Original:
We use feature branches on a git repository running on a GitLab server; with a webhook to poll jenkins on the git repository. We've several branches: master develop feature/A feature/B ... A user from doc team added some feature branches named with a capital letter: Feature/C Feature/D ... From this point, our job configured to build our application on feature branches commit detection with pattern */feature/${FEATURE_BRANCH} always built the same branch feature/A even if changes were made in feature/B etc. I reproduced the problem on a fresh git repository, reproducing a quick life of the repository; before the addition of Feature/C; everything ran fine. With the Addition of Feature/C; the problem occurred. When both feature and Feature branches were present; the polling was triggered by GitLab but the detection of the origin of the commit does not work on jenkins. I found as workaround to change my pattern from */feature/${FEATURE_BRANCH} to */*eature/${FEATURE_BRANCH} but I was expecting that even if feature branches were added starting with Feature instead of feature; the process would detect and get the commit on the right branch. |
New:
We use feature branches on a git repository running on a GitLab server; with a webhook to poll jenkins on the git repository. We've several branches: master develop feature/A feature/B ... A user from doc team added some feature branches named with a capital letter: Feature/C Feature/D ... From this point, our job configured to build our application on feature branches commit detection with pattern */feature/${FEATURE_BRANCH} always built the same branch feature/A even if changes were made in feature/B etc. I reproduced the problem on a fresh git repository, reproducing a quick life of the repository; before the addition of Feature/C; everything ran fine. With the Addition of Feature/C; the problem occurred. When both feature and Feature branches were present; the polling was triggered by GitLab but the detection of the origin of the commit does not work on jenkins. I found as workaround to change my pattern from */feature/${FEATURE_BRANCH} to */*eature/${FEATURE_BRANCH} but I was expecting that even if feature branches were added starting with Feature instead of feature; the process would detect and get the commit on the right branch. Some logs: Example of bad detection (last commit was not on the feature/sync branch): Cloning the remote Git repository Cloning repository git@git1.eu.lcom:mobilite/CollectionAndroid.git > C:\Progs\Git\bin\git.exe init c:\CI\workspace\LCatalog-android-feature-build # timeout=10 Fetching upstream changes from git@git.eu.lcom:mobilite/CollectionAndroid.git > C:\Progs\Git\bin\git.exe --version # timeout=10 > C:\Progs\Git\bin\git.exe -c core.askpass=true fetch --tags --progress git@git1.eu.lcom:mobilite/CollectionAndroid.git +refs/heads/*:refs/remotes/origin/* > C:\Progs\Git\bin\git.exe config remote.origin.url git@git1.eu.lcom:mobilite/CollectionAndroid.git # timeout=10 > C:\Progs\Git\bin\git.exe config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 > C:\Progs\Git\bin\git.exe config remote.origin.url git@git1.eu.lcom:mobilite/CollectionAndroid.git # timeout=10 Pruning obsolete local branches Fetching upstream changes from git@git1.eu.lcom:mobilite/CollectionAndroid.git > C:\Progs\Git\bin\git.exe -c core.askpass=true fetch --tags --progress git@srdspgit1.eu.lcom:mobilite/CollectionAndroid.git +refs/heads/*:refs/remotes/origin/* --prune Seen branch in repository origin/Feature/FicheC Seen branch in repository origin/Feature/Wording_13-01 Seen branch in repository origin/Feature/Wording_15-12 Seen branch in repository origin/Feature/account Seen branch in repository origin/Feature/change-decsription-button Seen branch in repository origin/Feature/change-tracking-ajustements Seen branch in repository origin/Feature/change_tracking Seen branch in repository origin/Feature/login Seen branch in repository origin/Feature/remove-guava Seen branch in repository origin/Feature/sync Seen branch in repository origin/develop Seen branch in repository origin/master Seen branch in repository origin/masterv5r1 Seen 13 remote branches Checking out Revision 5e63c5c7488bcdab1632467cc61bbae2dc67eb87 (refs/remotes/origin/feature/sync) > C:\Progs\Git\bin\git.exe config core.sparsecheckout # timeout=10 > C:\Progs\Git\bin\git.exe checkout -f 5e63c5c7488bcdab1632467cc61bbae2dc67eb87 > C:\Progs\Git\bin\git.exe rev-list 5e63c5c7488bcdab1632467cc61bbae2dc67eb87 # timeout=10 No emails were triggered. [EnvInject] - Executing scripts and injecting environment variables after the SCM step. [EnvInject] - Injecting as environment variables the properties content JAVA_HOME=C:\Progs\jdk-1.8.0_60 And the list of branches seen by Git command line; note that all feature branches are named with lower case names instead of the two Feature/Wording* branches: $ git branch --list --all * develop remotes/origin/HEAD -> origin/develop remotes/origin/develop remotes/origin/feature/FicheCad remotes/origin/feature/account remotes/origin/feature/advanced remotes/origin/feature/change-decsription-button remotes/origin/feature/change-tracking-ajustements remotes/origin/feature/change_tracking remotes/origin/feature/login remotes/origin/feature/remove-guava remotes/origin/feature/sync remotes/origin/Feature/Wording_11-01 remotes/origin/Feature/Wording_15-12 remotes/origin/master remotes/origin/masterv5r1 |
| Description |
Original:
We use feature branches on a git repository running on a GitLab server; with a webhook to poll jenkins on the git repository. We've several branches: master develop feature/A feature/B ... A user from doc team added some feature branches named with a capital letter: Feature/C Feature/D ... From this point, our job configured to build our application on feature branches commit detection with pattern */feature/${FEATURE_BRANCH} always built the same branch feature/A even if changes were made in feature/B etc. I reproduced the problem on a fresh git repository, reproducing a quick life of the repository; before the addition of Feature/C; everything ran fine. With the Addition of Feature/C; the problem occurred. When both feature and Feature branches were present; the polling was triggered by GitLab but the detection of the origin of the commit does not work on jenkins. I found as workaround to change my pattern from */feature/${FEATURE_BRANCH} to */*eature/${FEATURE_BRANCH} but I was expecting that even if feature branches were added starting with Feature instead of feature; the process would detect and get the commit on the right branch. Some logs: Example of bad detection (last commit was not on the feature/sync branch): Cloning the remote Git repository Cloning repository git@git1.eu.lcom:mobilite/CollectionAndroid.git > C:\Progs\Git\bin\git.exe init c:\CI\workspace\LCatalog-android-feature-build # timeout=10 Fetching upstream changes from git@git.eu.lcom:mobilite/CollectionAndroid.git > C:\Progs\Git\bin\git.exe --version # timeout=10 > C:\Progs\Git\bin\git.exe -c core.askpass=true fetch --tags --progress git@git1.eu.lcom:mobilite/CollectionAndroid.git +refs/heads/*:refs/remotes/origin/* > C:\Progs\Git\bin\git.exe config remote.origin.url git@git1.eu.lcom:mobilite/CollectionAndroid.git # timeout=10 > C:\Progs\Git\bin\git.exe config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 > C:\Progs\Git\bin\git.exe config remote.origin.url git@git1.eu.lcom:mobilite/CollectionAndroid.git # timeout=10 Pruning obsolete local branches Fetching upstream changes from git@git1.eu.lcom:mobilite/CollectionAndroid.git > C:\Progs\Git\bin\git.exe -c core.askpass=true fetch --tags --progress git@srdspgit1.eu.lcom:mobilite/CollectionAndroid.git +refs/heads/*:refs/remotes/origin/* --prune Seen branch in repository origin/Feature/FicheC Seen branch in repository origin/Feature/Wording_13-01 Seen branch in repository origin/Feature/Wording_15-12 Seen branch in repository origin/Feature/account Seen branch in repository origin/Feature/change-decsription-button Seen branch in repository origin/Feature/change-tracking-ajustements Seen branch in repository origin/Feature/change_tracking Seen branch in repository origin/Feature/login Seen branch in repository origin/Feature/remove-guava Seen branch in repository origin/Feature/sync Seen branch in repository origin/develop Seen branch in repository origin/master Seen branch in repository origin/masterv5r1 Seen 13 remote branches Checking out Revision 5e63c5c7488bcdab1632467cc61bbae2dc67eb87 (refs/remotes/origin/feature/sync) > C:\Progs\Git\bin\git.exe config core.sparsecheckout # timeout=10 > C:\Progs\Git\bin\git.exe checkout -f 5e63c5c7488bcdab1632467cc61bbae2dc67eb87 > C:\Progs\Git\bin\git.exe rev-list 5e63c5c7488bcdab1632467cc61bbae2dc67eb87 # timeout=10 No emails were triggered. [EnvInject] - Executing scripts and injecting environment variables after the SCM step. [EnvInject] - Injecting as environment variables the properties content JAVA_HOME=C:\Progs\jdk-1.8.0_60 And the list of branches seen by Git command line; note that all feature branches are named with lower case names instead of the two Feature/Wording* branches: $ git branch --list --all * develop remotes/origin/HEAD -> origin/develop remotes/origin/develop remotes/origin/feature/FicheCad remotes/origin/feature/account remotes/origin/feature/advanced remotes/origin/feature/change-decsription-button remotes/origin/feature/change-tracking-ajustements remotes/origin/feature/change_tracking remotes/origin/feature/login remotes/origin/feature/remove-guava remotes/origin/feature/sync remotes/origin/Feature/Wording_11-01 remotes/origin/Feature/Wording_15-12 remotes/origin/master remotes/origin/masterv5r1 |
New:
We use feature branches on a git repository running on a GitLab server; with a webhook to poll jenkins on the git repository. We've several branches: master develop feature/A feature/B ... A user from doc team added some feature branches named with a capital letter: Feature/C Feature/D ... From this point, our job configured to build our application on feature branches commit detection with pattern */feature/${FEATURE_BRANCH} always built the same branch feature/A even if changes were made in feature/B etc. I reproduced the problem on a fresh git repository, reproducing a quick life of the repository; before the addition of Feature/C; everything ran fine. With the Addition of Feature/C; the problem occurred. When both feature and Feature branches were present; the polling was triggered by GitLab but the detection of the origin branch of the commit does not work on jenkins. I found as workaround to change my pattern from */feature/${FEATURE_BRANCH} to */*eature/${FEATURE_BRANCH} but I was expecting that even if feature branches were added starting with Feature instead of feature; the process would detect and get the commit on the right branch. Some logs: Example of bad detection (last commit was not on the feature/sync branch): Cloning the remote Git repository Cloning repository git@git1.eu.lcom:mobilite/CollectionAndroid.git > C:\Progs\Git\bin\git.exe init c:\CI\workspace\LCatalog-android-feature-build # timeout=10 Fetching upstream changes from git@git.eu.lcom:mobilite/CollectionAndroid.git > C:\Progs\Git\bin\git.exe --version # timeout=10 > C:\Progs\Git\bin\git.exe -c core.askpass=true fetch --tags --progress git@git1.eu.lcom:mobilite/CollectionAndroid.git +refs/heads/*:refs/remotes/origin/* > C:\Progs\Git\bin\git.exe config remote.origin.url git@git1.eu.lcom:mobilite/CollectionAndroid.git # timeout=10 > C:\Progs\Git\bin\git.exe config --add remote.origin.fetch +refs/heads/*:refs/remotes/origin/* # timeout=10 > C:\Progs\Git\bin\git.exe config remote.origin.url git@git1.eu.lcom:mobilite/CollectionAndroid.git # timeout=10 Pruning obsolete local branches Fetching upstream changes from git@git1.eu.lcom:mobilite/CollectionAndroid.git > C:\Progs\Git\bin\git.exe -c core.askpass=true fetch --tags --progress git@srdspgit1.eu.lcom:mobilite/CollectionAndroid.git +refs/heads/*:refs/remotes/origin/* --prune Seen branch in repository origin/Feature/FicheC Seen branch in repository origin/Feature/Wording_13-01 Seen branch in repository origin/Feature/Wording_15-12 Seen branch in repository origin/Feature/account Seen branch in repository origin/Feature/change-decsription-button Seen branch in repository origin/Feature/change-tracking-ajustements Seen branch in repository origin/Feature/change_tracking Seen branch in repository origin/Feature/login Seen branch in repository origin/Feature/remove-guava Seen branch in repository origin/Feature/sync Seen branch in repository origin/develop Seen branch in repository origin/master Seen branch in repository origin/masterv5r1 Seen 13 remote branches Checking out Revision 5e63c5c7488bcdab1632467cc61bbae2dc67eb87 (refs/remotes/origin/feature/sync) > C:\Progs\Git\bin\git.exe config core.sparsecheckout # timeout=10 > C:\Progs\Git\bin\git.exe checkout -f 5e63c5c7488bcdab1632467cc61bbae2dc67eb87 > C:\Progs\Git\bin\git.exe rev-list 5e63c5c7488bcdab1632467cc61bbae2dc67eb87 # timeout=10 No emails were triggered. [EnvInject] - Executing scripts and injecting environment variables after the SCM step. [EnvInject] - Injecting as environment variables the properties content JAVA_HOME=C:\Progs\jdk-1.8.0_60 And the list of branches seen by Git command line; note that all feature branches are named with lower case names instead of the two Feature/Wording* branches: $ git branch --list --all * develop remotes/origin/HEAD -> origin/develop remotes/origin/develop remotes/origin/feature/FicheCad remotes/origin/feature/account remotes/origin/feature/advanced remotes/origin/feature/change-decsription-button remotes/origin/feature/change-tracking-ajustements remotes/origin/feature/change_tracking remotes/origin/feature/login remotes/origin/feature/remove-guava remotes/origin/feature/sync remotes/origin/Feature/Wording_11-01 remotes/origin/Feature/Wording_15-12 remotes/origin/master remotes/origin/masterv5r1 |
| Assignee | Original: Mark Waite [ markewaite ] |
| Resolution | New: Won't Fix [ 2 ] | |
| Status | Original: Open [ 1 ] | New: Resolved [ 5 ] |
| Status | Original: Resolved [ 5 ] | New: Closed [ 6 ] |
The Windows file systems are case insensitive. They see no difference between Feature/abc and fEaTuRe/abc.
Git stores branch name information in the file system as files and directories.
Because git stores branch name information in the file system as files and directories and the Windows file system is case insensitive, I don't think there is any way to resolve this issue on Windows.