The Problem
Currently, when building local Git CLI tooling, determining the base/target branch of a local feature branch requires a network call to the forge API (via git-pkgs/forge) to check for an open Pull/Merge Request.
Because Git tracks content and not intent, it has no native concept of a "base branch." For tools that run frequently (like local linting, pre-commit hooks, or stacked diff managers), constantly hitting the forge API is too slow and fails entirely if the user is offline or hasn't pushed their branch yet.
Proposed Solution
I propose adding a utility function (e.g., GetOrFetchBaseBranch) that acts as a caching layer between the local Git configuration and the remote Forge API.
The flow would look like this:
- Check the local
.git/config for a cached key (e.g., branch.<current-branch>.forge-merge-base).
- If the key exists, return it immediately (zero network overhead).
- If the key is missing, fetch the base branch via the existing Forge API logic.
- Persist the fetched result locally using
git config --local branch.<current-branch>.forge-merge-base <target> so subsequent runs are instant and offline-capable.
Why this approach?
By scoping the config key to branch.<name>, Git will natively garbage-collect the cached value when the user deletes the branch (git branch -d), preventing local config bloat. This also provides interoperability—if a user modifies the config manually, the tool respects it.
Alternative solution
Instead of forge-merge-base we could use vscode-merge-base, which is already available, when using VSCode.
Next Steps
Does this align with the scope of git-pkgs/forge? If you are open to this feature, I would be happy to put together a PR with the implementation.
A lot of tools miss that feature. Related:
The Problem
Currently, when building local Git CLI tooling, determining the base/target branch of a local feature branch requires a network call to the forge API (via
git-pkgs/forge) to check for an open Pull/Merge Request.Because Git tracks content and not intent, it has no native concept of a "base branch." For tools that run frequently (like local linting, pre-commit hooks, or stacked diff managers), constantly hitting the forge API is too slow and fails entirely if the user is offline or hasn't pushed their branch yet.
Proposed Solution
I propose adding a utility function (e.g.,
GetOrFetchBaseBranch) that acts as a caching layer between the local Git configuration and the remote Forge API.The flow would look like this:
.git/configfor a cached key (e.g.,branch.<current-branch>.forge-merge-base).git config --local branch.<current-branch>.forge-merge-base <target>so subsequent runs are instant and offline-capable.Why this approach?
By scoping the config key to
branch.<name>, Git will natively garbage-collect the cached value when the user deletes the branch (git branch -d), preventing local config bloat. This also provides interoperability—if a user modifies the config manually, the tool respects it.Alternative solution
Instead of
forge-merge-basewe could usevscode-merge-base, which is already available, when using VSCode.Next Steps
Does this align with the scope of
git-pkgs/forge? If you are open to this feature, I would be happy to put together a PR with the implementation.A lot of tools miss that feature. Related: