Create dialog to inform that current branch is not managed by plugin

[azdrojowa123]

Create some kind of dialog to inform user that current branch is not managed by plugin. Maybe create some checkbox to add this branch to plugin. Add also button to Don't ask again about this issue.

[PawelLipski]

Dialog should be non-modal, we don't want it be intrusive.

create some checkbox to add this branch to plugin

I'd even say, it can be button/link (rather than checkbox per se).

The inferred parent (or lack thereof, if com.virtuslab.gitmachete.backend.api.IGitMacheteRepository#inferParentForLocalBranch returns Option.none()) should be mentioned in the dialog as well.

[mkondratek]

What's the specific scenario for this one?

1. Be on a managed branch
2. Checkout non-managed branch (from command line / git4idea)
3. Show VcsNotification with an action to add the non-managed branch under the inferred parent.

Is that it?

---

Notes:

• We need handling for no-managed root branches - where the parent cannot be inferred (I suppose).
• What if the inferred parent is different from what a user expects? The VcsNotification could have two actions (despite Dismiss or smth). Accept or Accept and edit Machete file
• Such a notification should take an expiration into account. I think that another checkout or Machete file edit belongs to actions that would make the notification expired (no longer valid) - probably there is more of them.

[PawelLipski]

Is that it?

:yes:

We need handling for no-managed root branches - where the parent cannot be inferred (I suppose).

+1, suggest to add them as a root

What if the inferred parent is different from what a user expects? The VcsNotification could have two actions (despite Dismiss or smth). Accept or Accept and edit Machete file

+1, should be enough

Such a notification should take an expiration into account. I think that another checkout or Machete file edit belongs to actions that would make the notification expired (no longer valid) - probably there is more of them.

+1, good spot, I didn't think of that

[mkondratek]

Writing it just for a log.

The topic

BranchChangeListener.VCS_BRANCH_CHANGED

is not good enough for us. I took a look into what comes to com.intellij.openapi.vcs.BranchChangeListener#branchHasChanged(String branchName) and I saw HEAD, f47545bb46bdfe280a2f80e37925d5df6918be1f, build-chain^{0} and sometimes correct result - the newly checked out branch

I think we must rely on

GitRepository.GIT_REPO_CHANGE

and most likely have our own implementation of branch change tracking.

[PawelLipski]

and sometimes correct result

Okay... so specifically what were the wrong results? i.e. what's the reason we can't rely on VCS_BRANCH_CHANGED?

[mkondratek]

The "wrong" ones are those I listed: HEAD, f47545bb46bdfe280a2f80e37925d5df6918be1f, build-chain^{0}.

[PawelLipski]

Okay... and what was expected? That none of them shows up? 🤔

[PawelLipski]

So, in a nutshell, when VCS_BRANCH_CHANGED is used, do we experience false positives (superfluous notifications) or false negatives (missing notifications)?

[mkondratek]

I would expect the name of a branch that I ve checked out 😆 the above ones even might refer to the same thing (the branch) but we need simply a name (that's why I would not call them "false" or "wrong"). Also iirc they appear when a new branch is being created and checked out (but when I perform checkout only the result is better).

Another thing is that the branchHasChanged does not cover all cases. When you change the branch from command line and then move back to IDE window the topic is not being synced (it is not triggered). On the other hand, GitRepository.GIT_REPO_CHANGE works in that case correctly.

[mkondratek]

It turned out that we need #1285 before this one.