Add support for git flow using the git-flow-next tool#5288
Conversation
|
Is there any progress on this PR? |
Just this morning I was wondering the same thing. Is there anything I can do to move this forward? |
I really need this feature, and I really hope this PR can be merged. |
|
I need this feature too. Please merge this PR. |
|
I also need this feature, so please merge the PR. |
Lift the inline parsing in FinishCmdObj into parseGitFlowPrefixMap on ConfigCommands. The caller now does a direct map lookup against the parsed prefix → branchType map instead of iterating the raw config output and suffix-matching. This is preparation for adding git-flow-next support, which needs to merge a second config schema into the same map. One incidental change: a branch name without a slash now returns NotAGitFlowBranch immediately, rather than falling through the line loop with an empty suffix. Previously a configured gitflow.prefix.X whose value happened to equal the entire branch name could match — never a useful outcome.
git-flow-next (https://github.com/gittower/git-flow-next) uses a different config schema than legacy git-flow: gitflow.branch.<type>.prefix instead of gitflow.prefix.<type>. Recognize both schemas in GetGitFlowPrefixMap by querying each and merging into a single prefix → branchType map. GitFlowEnabled now consults the merged map so a next-only setup counts as enabled. When both schemas configure the same prefix, the legacy entry wins. In normal usage both schemas agree, so the rule mainly matters as a deterministic tie-breaker.
Make the "legacy wins" scenarios actually distinguish legacy from next.
Both sides used the same branchType ("feature"), so the assertion would
pass equally well under a "next wins" rule — the test didn't pin the
conflict-resolution behavior it was named for. Give legacy and next
distinct types so a regression in the merge order would be caught.
Both getGitFlowPrefixes and getGitFlowNextPrefixes are only called by GetGitFlowPrefixMap in the same file, so they don't need package-external visibility. The merged map returned by GetGitFlowPrefixMap is the only abstraction the rest of the package needs.
stefanhaller
force-pushed
the
enable-git-flow-next-as-the-git-flow-tool
branch
from
8c3272c to
405d883
Compare
|
Sorry for the delay. I'm not a git-flow user, so I can't test this myself; and I'm also unfamiliar with our code around git-flow, so I couldn't meaningfully review it. I asked Claude to do a code review, and it came up with two fixups; also, it recommended to split the commit in two (prep refactor and actual change), so I had it do that too (with more elaborate commit messages). It kept you as the author of both commits, let me know if you object to that; we could also put me in as the author and add you as Co-authored-by; just let me know what you prefer. Does anybody here want to test it again before I merge? |
5 participants
This change enables Lazygit
git-flowintegration to work withgit-flow-next. The "official"git-flowhas been deprecated and replaced bygit-flow-next.got-flow-nexthas the same tool and most of the functionality is compatible but thegit configis different so Lazygit doesn't recognise it.