shoko/kugetsu
1
0
Fork 0
Code Issues 17 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

Better git server config/management for issue refs #78

New Issue
Closed
opened 2026-04-01 23:12:36 +02:00 by shoko · 4 comments
shoko commented 2026-04-01 23:12:36 +02:00
Owner
Copy Link

Problem

When delegating work via kugetsu start github.com/shoko/kugetsu#76, the tool needs to determine the actual git clone URL. Currently this is handled in two places:

  1. repos.json (~/.kugetsu/repos.json) — a manual mapping of issue ref to repo URL
  2. Fallback URL builder in get_repo_url() — constructs URL from issue ref format

repos.json approach

Entries must be pre-registered before kugetsu start works. If an issue ref is not in repos.json, it falls through to the fallback.

Fallback URL builder (current)

For github.com/shoko/kugetsu#76, the fallback builds:

https://github.com/shoko/kugetsu.git

Two problems:

  1. Wrong git server instance — this assumes github.com, but the actual repo may be on git.fbrns.co. The fallback has no way to know which git server to use.
  2. Owner sometimes missing — the original fallback (before patch) built https://github.com/kugetsu.git (missing shoko). The patched version includes owner but still wrong instance.

extract_issue_ref_from_message() bug (related)

When delegating via full URL (e.g., https://git.fbrns.co/shoko/kugetsu/issues/78), the function that parses URLs is broken:

local path=$(echo "$url" | grep -oE "/[^/]+/[^/]+/[^/]+")

For https://git.fbrns.co/shoko/kugetsu/issues/78, this incorrectly captures from the protocol part (://git.fbrns.co) instead of the path part (/shoko/kugetsu), producing garbage like git.fbrns.co/git.fbrns.co/shoko/issues#78 instead of git.fbrns.co/shoko/kugetsu#78.

This makes URL-based delegation fail even when repos.json has the correct entry.

Current workaround

Manually add entries to repos.json before delegating:

{"github.com/shoko/kugetsu#76": "https://git.fbrns.co/shoko/kugetsu.git"}

This is error-prone and requires manual steps before delegation.

Proposed solutions

Option A: Git server registry

Add a config file (e.g., ~/.kugetsu/servers.json) that maps git hostnames to instances:

{
  "github.com": "github.com",
  "git.fbrns.co": "git.fbrns.co"
}

Then get_repo_url uses the issue ref hostname directly, falling back to github.com only for bare github.com refs with no known git server.

Option B: Default server per namespace

Allow repos.json entries to use short keys that map to specific git servers:

{
  "github.com/shoko/kugetsu": "https://git.fbrns.co/shoko/kugetsu.git"
}

get_repo_url would try progressively shorter keys until it finds a match.

Option C: Delegate self-registration

PM agent automatically adds issue refs to repos.json before calling kugetsu start. Requires PM agent to know the correct repo URL ahead of time.

Questions

  1. Should kugetsu support multiple git server instances (github.com, git.fbrns.co, gitlab.com, etc.)?
  2. Should the default "github.com" mapping always point to github.com, or should it be configurable?
  3. Is there a better UX where users configure their git server mappings once and kugetsu auto-detects?
  4. Should extract_issue_ref_from_message URL parsing be fixed as part of this issue, or split into a separate bugfix?

References

  • Related: PM agent delegation workflow for issue #76
  • Related: extract_issue_ref_from_message() URL parsing bug (see description above)
## Problem When delegating work via `kugetsu start github.com/shoko/kugetsu#76`, the tool needs to determine the actual git clone URL. Currently this is handled in two places: 1. **repos.json** (`~/.kugetsu/repos.json`) — a manual mapping of issue ref to repo URL 2. **Fallback URL builder** in `get_repo_url()` — constructs URL from issue ref format ### repos.json approach Entries must be pre-registered before `kugetsu start` works. If an issue ref is not in repos.json, it falls through to the fallback. ### Fallback URL builder (current) For `github.com/shoko/kugetsu#76`, the fallback builds: ``` https://github.com/shoko/kugetsu.git ``` Two problems: 1. **Wrong git server instance** — this assumes github.com, but the actual repo may be on `git.fbrns.co`. The fallback has no way to know which git server to use. 2. **Owner sometimes missing** — the original fallback (before patch) built `https://github.com/kugetsu.git` (missing `shoko`). The patched version includes owner but still wrong instance. ### extract_issue_ref_from_message() bug (related) When delegating via full URL (e.g., `https://git.fbrns.co/shoko/kugetsu/issues/78`), the function that parses URLs is broken: ```bash local path=$(echo "$url" | grep -oE "/[^/]+/[^/]+/[^/]+") ``` For `https://git.fbrns.co/shoko/kugetsu/issues/78`, this incorrectly captures from the protocol part (`://git.fbrns.co`) instead of the path part (`/shoko/kugetsu`), producing garbage like `git.fbrns.co/git.fbrns.co/shoko/issues#78` instead of `git.fbrns.co/shoko/kugetsu#78`. This makes URL-based delegation fail even when repos.json has the correct entry. ## Current workaround Manually add entries to repos.json before delegating: ```json {"github.com/shoko/kugetsu#76": "https://git.fbrns.co/shoko/kugetsu.git"} ``` This is error-prone and requires manual steps before delegation. ## Proposed solutions ### Option A: Git server registry Add a config file (e.g., `~/.kugetsu/servers.json`) that maps git hostnames to instances: ```json { "github.com": "github.com", "git.fbrns.co": "git.fbrns.co" } ``` Then `get_repo_url` uses the issue ref hostname directly, falling back to github.com only for bare `github.com` refs with no known git server. ### Option B: Default server per namespace Allow repos.json entries to use short keys that map to specific git servers: ```json { "github.com/shoko/kugetsu": "https://git.fbrns.co/shoko/kugetsu.git" } ``` `get_repo_url` would try progressively shorter keys until it finds a match. ### Option C: Delegate self-registration PM agent automatically adds issue refs to repos.json before calling `kugetsu start`. Requires PM agent to know the correct repo URL ahead of time. ## Questions 1. Should kugetsu support multiple git server instances (github.com, git.fbrns.co, gitlab.com, etc.)? 2. Should the default "github.com" mapping always point to github.com, or should it be configurable? 3. Is there a better UX where users configure their git server mappings once and kugetsu auto-detects? 4. Should `extract_issue_ref_from_message` URL parsing be fixed as part of this issue, or split into a separate bugfix? ## References - Related: PM agent delegation workflow for issue #76 - Related: `extract_issue_ref_from_message()` URL parsing bug (see description above)
han commented 2026-04-01 23:20:23 +02:00
Copy Link

kugetsu could support multiple git server instances, and the example right now is sufficient.

default fallback from the kugetsu init should always refer to github.com, but yes its should be configurable in a way that we could change the default midway without restarting kugetsu

what do you think of a dedicated command for a better UX? like for example "getting a git server" it will fallback to default one if not given, then we can verify if the fallback value is our wanted git server or not. we can also list all the git server that we have. we can add them as well. I think its the same think for the git server's username and repositories as well. do you have suggestions?

kugetsu could support multiple git server instances, and the example right now is sufficient. default fallback from the kugetsu init should always refer to github.com, but yes its should be configurable in a way that we could change the default midway without restarting kugetsu what do you think of a dedicated command for a better UX? like for example "getting a git server" it will fallback to default one if not given, then we can verify if the fallback value is our wanted git server or not. we can also list all the git server that we have. we can add them as well. I think its the same think for the git server's username and repositories as well. do you have suggestions?
shoko commented 2026-04-01 23:51:00 +02:00
Author
Owner
Copy Link

Thanks for the feedback han. Delegating to PM to review and respond to your suggestions about dedicated git-server commands. Will update shortly.

Thanks for the feedback han. Delegating to PM to review and respond to your suggestions about dedicated git-server commands. Will update shortly.
shoko added the task-delegation label 2026-04-02 00:30:42 +02:00
shoko commented 2026-04-02 00:37:02 +02:00
Author
Owner
Copy Link

Implementation Proposal

Based on the discussion, here is my proposed implementation:

1. Server Configuration File (~/.kugetsu/servers.json)

{
  "github.com": "https://github.com",
  "git.fbrns.co": "https://git.fbrns.co",
  "default": "github.com"
}

2. New kugetsu server Command

kugetsu server add <name> <url>   # Add a git server
kugetsu server list                # List all configured servers
kugetsu server default [<name>]   # Get/set default server
kugetsu server get <name>         # Get URL for a server

3. Modified get_repo_url() Logic

get_repo_url() {
    local issue_ref="$1"
    
    # 1. Check repos.json for direct mapping
    if [ -f "$REPOS_CONFIG" ]; then
        url=$(python3 -c "import json; print(json.load(open("$REPOS_CONFIG")).get("$issue_ref", ""))")
        [ -n "$url" ] && echo "$url" && return
    fi
    
    # 2. Parse instance from issue ref
    instance=$(echo "$issue_ref" | cut -d"/" -f1 | cut -d"#" -f1)
    
    # 3. Check if instance matches a configured server
    if [ -f "$SERVERS_CONFIG" ]; then
        server_url=$(python3 -c "import json; print(json.load(open("$SERVERS_CONFIG")).get("$instance", ""))")
        if [ -n "$server_url" ]; then
            rest=$(echo "$issue_ref" | sed "s/.*\/\/[^\/]*//" | sed "s/#.*//")
            echo "${server_url}/${rest}.git"
            return
        fi
    fi
    
    # 4. Fall back to default server
    default_server=$(python3 -c "import json; print(json.load(open("$SERVERS_CONFIG")).get("default", "https://github.com"))")
    rest=$(echo "$issue_ref" | sed "s/.*\/\/[^\/]*//" | sed "s/#.*//")
    echo "${default_server}/${rest}.git"
}

4. Questions

  1. Should we auto-detect the default server during kugetsu init (e.g., extract from git config)?
  2. Should we support server aliases (e.g., "gh" -> "https://github.com")?
  3. Is servers.json the right filename, or should it be part of the existing config file?

Does this approach make sense? Any preferences on naming or structure?

## Implementation Proposal Based on the discussion, here is my proposed implementation: ### 1. Server Configuration File (`~/.kugetsu/servers.json`) ```json { "github.com": "https://github.com", "git.fbrns.co": "https://git.fbrns.co", "default": "github.com" } ``` ### 2. New `kugetsu server` Command ```bash kugetsu server add <name> <url> # Add a git server kugetsu server list # List all configured servers kugetsu server default [<name>] # Get/set default server kugetsu server get <name> # Get URL for a server ``` ### 3. Modified `get_repo_url()` Logic ```bash get_repo_url() { local issue_ref="$1" # 1. Check repos.json for direct mapping if [ -f "$REPOS_CONFIG" ]; then url=$(python3 -c "import json; print(json.load(open("$REPOS_CONFIG")).get("$issue_ref", ""))") [ -n "$url" ] && echo "$url" && return fi # 2. Parse instance from issue ref instance=$(echo "$issue_ref" | cut -d"/" -f1 | cut -d"#" -f1) # 3. Check if instance matches a configured server if [ -f "$SERVERS_CONFIG" ]; then server_url=$(python3 -c "import json; print(json.load(open("$SERVERS_CONFIG")).get("$instance", ""))") if [ -n "$server_url" ]; then rest=$(echo "$issue_ref" | sed "s/.*\/\/[^\/]*//" | sed "s/#.*//") echo "${server_url}/${rest}.git" return fi fi # 4. Fall back to default server default_server=$(python3 -c "import json; print(json.load(open("$SERVERS_CONFIG")).get("default", "https://github.com"))") rest=$(echo "$issue_ref" | sed "s/.*\/\/[^\/]*//" | sed "s/#.*//") echo "${default_server}/${rest}.git" } ``` ### 4. Questions 1. Should we auto-detect the default server during `kugetsu init` (e.g., extract from git config)? 2. Should we support server aliases (e.g., "gh" -> "https://github.com")? 3. Is `servers.json` the right filename, or should it be part of the existing config file? Does this approach make sense? Any preferences on naming or structure?
han commented 2026-04-02 00:42:06 +02:00
Copy Link

in the kugetsu server command, is there no modify and delete command? I think during init, we should prompt to user if they want to add new server or left as default one (github). no server aliases are not needed right now, it can be for improvement but not for this blocking issue. yes I think servers.json is good enough.

but the question can we utilize the kugetsu config file instead of making a new servers json file? what do you think?

in the kugetsu server command, is there no modify and delete command? I think during init, we should prompt to user if they want to add new server or left as default one (github). no server aliases are not needed right now, it can be for improvement but not for this blocking issue. yes I think servers.json is good enough. but the question can we utilize the kugetsu config file instead of making a new servers json file? what do you think?
shoko closed this issue 2026-04-02 02:27:42 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
0.2.x-only
Available only in 0.2.x, not backportable
 0.3.x-only
Available only in 0.3.x, not backportable
 backport
Backport compatible - can merge to 0.1.x
 blocked
Issue needs clarification/discussion before it can be worked on
 bug
Bug report
 critical
Critical - blocking parallel work
 feature
New feature
 foundation
Foundation work for 0.2.x
 high
High priority - workflow improvements
 meta
Meta issue tracking multiple issues
 need-review
PR needs review before merge
 parallelization
Issues related to parallelization
 ready
Issue is clear and ready to be implemented/delegated
 ready-to-merge
PR approved and ready to merge
 task-delegation
Issues related to task-delegation
No Label task-delegation
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
shoko
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: shoko/kugetsu#78
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?