[acidtrucks]

I love this because I started building a small utility to help me consistently track issues inside my project files like tickets/{folders}/{file }.md inside my projects, because I do not need an enterprise level management system, and I also really like the idea of tickets moving and closing as a part of merges, IMO it provides a better context when looking through history.

This is clearly more elegant, though it adds a new dependency, which is OK.

[carlmr]

>I also really like the idea of tickets moving and closing as a part of merges

I really like that, too, I wish we'd track our requirements in git instead of having an IBM enterprise solution which is slow, has a terrible web interface and no ability to diff requirements properly.

The more information is versioned in the same system, the better the coherence of the information.

[codethief]

> I also really like the idea of tickets moving and closing as a part of merges

So does that mean that bug reports are tied to branches? (I.e. depending on which branch you've checked out, you see a different list of bugs?) I wouldn't like that idea at all because how would you keep track of bugs (and related discussions) across branches? (For instance, having 10 branches would imply that you suddenly have 10 versions of the same bug discussion, too.)

[acidtrucks]

It does pose a significant problem.

I see more value in it for clear technical tasks with technical descriptions, and not so much for discussions. Then proposals can be peer-reviewed before accepted as work that needs to be done (as a merge request to master, for example).

Then another problem that comes along with that, especially for golang users, is that your master branch is getting bombarded with issue updates, causing what looks like releases, when there's no effective change.

[Hendrikto]

Not necessarily. All 10 branches could refer to the same discussion.