"gh repo rename" should rename the local directory

[mtfurlan]

Describe the feature or problem you’d like to solve

When I run gh repo rename, I want to rename both the github repo and my local directory

Proposed solution

Given that it already prompts, I think adding a prompt for "rename local directory" would be fine

The only issue is we would have to rethink what --yes means, and I can't think of a great ux for that without renaming --yes which is a bad idea

[jtmcg]

🤔 This seems like a reasonable bit of behavior, but I'm a bit hung up on this possibly being a bit outside the scope of gh because renaming your local directory is a non-git or GitHub related thing. However, in looking at other gh repo <subcommand> behavior, particularly gh repo create, the result is a directory that matches the name of repo, if you prompt or flag the command properly. git also seems to be opinionated about repo names matching directory names, as the default behavior of cloning a repo is to copy the repo name as the directory name.

As such, I think this enhancement makes sense. I'll attach some AC. Thanks for the suggestion, @mtfurlan 🙌

[jtmcg]

Design

# When the user doesn't specify anything
$ gh repo rename
? Rename <owner/repo> to: <new-name>
? Would you also like to rename the local directory to the same name? (y/N) y
✓ Renamed repository owner/<new-name> and local directory
✓ Updated the "origin" remote

# When the user specifies the repo name
$ gh repo rename <new-name>
? Rename <owner/repo> to <new-name>? (y/N) y
✓ Renamed repository owner/<new-name>
✓ Updated the "origin" remote

# When the user includes the --rename-dir flag
$ gh repo rename --rename-dir
? Rename <owner/repo> and local directory to: <new-name>
✓ Renamed repository owner/<new-name> and local directory
✓ Updated the "origin" remote

# When the user specifies the repo name and includes the --rename-dir flag
$ gh repo rename <new-name> --rename-dir
? Rename <owner/repo> to <new-name> and the local directory name? (y/N) y
✓ Renamed repository owner/<new-name> and local directory
✓ Updated the "origin" remote

# When the user specifies the repo name and includes the --rename-dir and --yes flags
$ gh repo rename <new-name> --rename-dir --yes
✓ Renamed repository owner/<new-name> and local directory
✓ Updated the "origin" remote

Acceptance Criteria

• [ ] Functionality is added to gh repo rename to rename the local directory following the design above
• [ ] The relevant documentation is updated

Note: The --yes flag will remain unchanged, as the expected default behavior is to NOT rename the directory. Since a flag is needed to be passed in for this behavior to occur, there is already sufficient user-intervention to keep --yes unchanged.

[mtfurlan]

Sounds reasonable to me

I would also recommend documenting that rename cannot transfer ownership, <new-name> does not mean $owner/$repo like it does in most gh commands gh rename $owner/$repo results in the final name $owner/$owner-$repo which I didn't realize for a few hours

[jtmcg]

Sounds reasonable to me

I would also recommend documenting that rename cannot transfer ownership, <new-name> does not mean $owner/$repo like it does in most gh commands gh rename $owner/$repo results in the final name $owner/$owner-$repo which I didn't realize for a few hours

Ah, interesting... To clarify, you were expecting gh repo rename to also change the owner on GitHub, so the end result would be renaming AND moving the repo to a new owner/repo?

[mtfurlan]

Ah, interesting... To clarify, you were expecting gh repo rename to also change the owner on GitHub, so the end result would be renaming AND moving the repo to a new owner/repo?

I was expecting to have to pass the owner, because most gh commands take repo argument in the form $owner/$repo

I don't think it's reasonable for reanme to change ownership though, I vaguely remember that being an entire process where both sides have to do a confirm step or something?

[jtmcg]

Gotcha. So for many commands, we assume $owner based on your current directory, similarly to what we did here. You can often specify $owner/$repo if trying to perform an operation outside of your current repo/directory. In fact, the [--repo flag in gh repo rename](https://cli.github.com/manual/gh_repo_rename) does just that, and takes the <[host/]owner/repo> arg. I think since it's documented by the flag we probably don't need to add additional documentation here.

I appreciate the callout, though. We'll keep an eye out to see if this trips up other folks and revisit if needed 🙂

[benebsiny]

Is this possible to implement? When using gh repo rename to change the folder name of the current repository, since you are inside that folder, you should encounter an error message like "the process cannot access the folder because it is being used by another process."

[jtmcg]

Is this possible to implement? When using gh repo rename to change the folder name of the current repository, since you are inside that folder, you should encounter an error message like "the process cannot access the folder because it is being used by another process."

I guess I'd need to see a PoC to confirm, but I think this could probably just be accomplished with an extra operation that occurs after the current gh repo rename behavior. Perhaps we allow the flag, like --rename-dir to execute a mv <old-repo-name> <new-repo-name> type command in sequence?

[benebsiny]

Here’s the PoC I made. I also did some research and found that when you run gh repo rename, the process's working directory is the folder you are trying to rename. This is why the previously mentioned error message occurs.

Therefore, a possible implementation, as you mentioned, would involve executing the mv command after the gh process has completed. But I’m not sure if this approach would be considered too outside the scope of gh.

[jtmcg]

Here’s the PoC I made. I also did some research and found that when you run gh repo rename, the process's working directory is the folder you are trying to rename. This is why the previously mentioned error message occurs.

Therefore, a possible implementation, as you mentioned, would involve executing the mv command after the gh process has completed. But I’m not sure if this approach would be considered too outside the scope of gh.

That's a great start, @benebsiny. Could you open a PR for it so we can get a conversation going on the code?

[benebsiny]

@jtmcg Sure thing! Have a look at the linked draft pull requests

[Maryamajamekramy]

1b0d216da8a5e810e811897db00de0f5 @.***

در تاریخ دوشنبه ۲ دسامبر ۲۰۲۴، ۱۰:۰۳ Giorgi Meskhidze < @.***> نوشت:

---

— Reply to this email directly, view it on GitHub https://github.com/cli/cli/issues/9695#issuecomment-2510689509, or unsubscribe https://github.com/notifications/unsubscribe-auth/BKCISOW4YTMBEERWGMVSS3D2DP5MRAVCNFSM6AAAAABPHZ5GYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMJQGY4DSNJQHE . You are receiving this because you are subscribed to this thread.Message ID: @.***>