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.
The services config has been the path for GHE for a while (for the
View-PR-URL feature) but it now does double duty: it's also what enables
the branches-panel PR icons for non-github.com hosts. Worth calling out
explicitly so users don't assume it's still github.com-only.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Both of these badges have the coloring logic to show stable releases in blue,
and prereleases in orange. The criterion for a prerelease is that the major
version is 0. Now it is debatable whether we consider lazygit "stable", but I
don't feel we are in a preliminary state of the project, working towards the
first final 1.0 release, so I feel blue expresses the state of the project
better.
The old link was broken, it would have to be "Formula/l/lazygit.rb" instead of
"Formula/lazygit.rb".
However, I don't find it very useful to link to the raw formula file, so I
decided to change the link to point to the homebrew web page for lazygit.
The core homebrew formular is usually up to date very quickly, so there's little
reason to use the custom tap.
We still maintain the tap and update it for the benefit of users who already
subscribed to it, but we no longer recommend it.
configuration.nix is a file, and most files in the README.md are
stylized as code blocks. `environment.systemPackages` is actually just a
code block, and should be stylized as such