-
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
-
JENKINS-75377 A Git conflict caused by names being the same except for the case of the letters on a case insensitive file system
-
- 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 ] |
Link |
New:
This issue is related to |