undefined

points

[-]

The issue there was collaboration, one person would be on master and see no hint that a case was already being worked on (status, comments, etc all being different until the branch was merged). The other bullets, that put the information in different locations, were attempts to deal with this.

by drabbiticus6 hours ago|

prev|

[-]

I can somewhat understand your point about issues tied to branch, but have some remaining questions about how this working in practice:

- If I am on a branch where this issue exists and unaddressed, is it easy to find out if there is another branch where this issue has been addressed

- I am on a branch that does not have the issue reported, but know it's reported on another branch -- does that mean the issue doesn't exist on this branch? Is it on the reporter to correctly identify the root branch where the issue was first created? Do you have to somehow merge to make this work "right"?

by lelanthran4 hours ago|

parent|

[-]

I haven't actually tried in practice (across a team I mean), but:

> - If I am on a branch where this issue exists and unaddressed, is it easy to find out if there is another branch where this issue has been addressed

I do not have a solution for that.

> - I am on a branch that does not have the issue reported, but know it's reported on another branch -- does that mean the issue doesn't exist on this branch?

The idea was to create issues only on on a separate branch which is constantly merged into master. Then all branches downstream of master will get the issue when they rebase/pull.

Scenarios:

1. You're on branch `x/y/z`, you notice something that should be added to the issue tracker, you stash, switch to `/issues`, add the issue, push, switch back to `x/y/z` and pop.

2. An issue is to be created, the creator clones `/issues`, creates the issue, and pushes.

This way, all issues are on all branches, but only the branch dealing with an issue will update it.