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. |
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? |
stefanhaller
force-pushed
the
enable-git-flow-next-as-the-git-flow-tool
branch
from
405d883 to
cb631c1
Compare
|
@hmaddocks Could you have a look please? I'm reluctant to merge this without your approval. For the others who commented here: did any of you built the branch from source and tried it (after my changes)? |
|
@stefanhaller I've tried the PR by running it from the source and initializing git flow in the lazygit repo via compared to the stable release which pops up an error: |
|
Hi, sorry for the late response. I have tested this and it works as I would expect. Happy with the new commits once CI is happy :) |
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.
stefanhaller
force-pushed
the
enable-git-flow-next-as-the-git-flow-tool
branch
from
cb631c1 to
dd0d908
Compare
6 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.