Jason Kankiewicz

> when a hotfix is closed/released it should merge to support branch AND developer AND master It **should** be automatically merged into the support branch upon which it was based...

This is related to #407 and #463 in that there should be a corresponding `git flow` command for every vanilla `git` command that can potentially invalidate the "[git flow ...]"...

> I propose a git flow cleanup that walks over those entries and removes them from the config file if the corresponding branches no longer exist... @Shea690901, that's a great...

> Am I missing something from this? Shouldn't support branches also have a main+develop pair? @srevinsaju, a support branch should *not* have a main+develop pair; a support branch is for...

The [Incorporating a finished feature on develop](http://nvie.com/posts/a-successful-git-branching-model/#incorporating-a-finished-feature-on-develop) section of [A successful Git branching model](http://nvie.com/posts/a-successful-git-branching-model/) doesn't make an exception for a feature branch with only one commit on so it would...

What if the issue's description is edited later? The only identifying aspect of an issue that's immutable is its ID so that's all that should be used to relate its...

At most this hook should validate that the feature/bugfix name can be mapped to an issue unambiguously; preventing a non-conforming branch from being created is not as bad as mutating...

@kat-co, thanks for opening the issue! Which platform are you attempting to build it on?

> @jkankiewicz any insights? I'll probably have to do some tinkering to make it work again. @alexjg, it would help me to reproduce and correct the issue if PR #843...

> I wanted to update automerge-go, but I can't build it because the current steps for automerge-go require macos. @stephen, don't worry about it; automerge-go only links to the automerge_core...