# New branch analysis picking older codes and issues

**URL:** <https://community.sonarsource.com/t/new-branch-analysis-picking-older-codes-and-issues/45761>\
**Category:** SonarQube Server / Community Build\
**Tags:** scanner\
**Created:** [July 1, 2021, 11:37am UTC](https://community.sonarsource.com/t/new-branch-analysis-picking-older-codes-and-issues/45761 "2021-07-01T11:37:33Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![OlivierK](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/olivierk/32/11116_2.png) [@OlivierK](https://community.sonarsource.com/u/OlivierK)\
**Post date:** [July 2, 2021, 8:47am UTC](https://community.sonarsource.com/t/new-branch-analysis-picking-older-codes-and-issues/45761/5 "2021-07-02T08:47:48Z")

</div>

Hello,

So I understand that your branch where some issues are raised unexpectedly is “some-branch” (I can’t see its name in your screenshots, that’s why I always ask to provide **full page** screenshot to see all the information, even the info that may not seem important), uses reference branch as new code definition and the reference branch is `develop`.

There is a subtle distinction between definition of new code and new issues.

When you chose new code as reference branch, there is not particular moment where the new code starts. It simply diffs the branch and the reference branch. In you case I guess the branch was created 7 months ago so that’s why you new code period is said to be 7 months.

The issue you highlight is 6 months old, meaning that it did not exist (on the **develop** branch or on the **some-branch** branch. So it was necessarily marked as _Won’t Fix_ on **develop** after creation of **some-branch**. That explains why the issue is raised on **some-branch** :

The manual changes on status of issues (WF, FP, Change of Severity, Type, Comments) is synchronized between branches **only at branch creation time (ie first first branch analysis)**. In your case all WF existing 7 months ago on develop would have been propagated on **some-branch**. This does not happen anymore afterwards. So the WF set on **develop** after the branch analysis did not make it to **some-branch**. That’s why this issue is there.

Assuming you use git for your source control, after `git checkout some-branch`, if you `git rebase develop` or `git merge develop` the issues that were injected in **develop** after forking **some-branch** :

- will land on **some-branch** as new issues (but they are not on some new code). Their status from **develop** (Won’t Fix or whatever) is **not** propagated on **some-branch**
- Normally the beginning of the new code period in **some-branch** should be reset to the moment you you `git merge` or `git rebase`.

From the 2nd bulletpoint above I am therefore surprised that your new code period on **some-branch** is still 7 months ! I can only see 2 reasons for that:

- You don’t use git as version control. SVN maybe ?
- You use git as version control bt don’t merge **develop** changes in **some-branch** using `git merge` or `git rebase`. Would that be possible ?

Olivier

---

_[View the full topic](https://community.sonarsource.com/t/new-branch-analysis-picking-older-codes-and-issues/45761)._