Implement Clone-as-Submodule feature

[yasuo-ozu]

Background

There are some needs to manage your ghq root as git repository, for syncing your local stubs, etc.

Changes

This PR changes the default behavior of ghq get like:

• Check if the target directory is inside git worktree of another git repository.
• If so, use git submodule add instead.

[Songmu]

Thanks for the pull request.
It's an exciting idea to git manage the whole ghq root, but I don't hear much else about the need for it, and honestly, I'm not so positive about including this feature.
I'll stay open to it for a while, but if no one appears who agrees with this feature, I'll close it later.

[yasuo-ozu]

Thanks for reply. I am considering following situations.

• Using multiple devices (for example, note pc and desktop pc)
• I want to manage local repos, which I am working now.
• ~/ghq directory is a git repo (origin is set to my github.com private repo)
  (local repos managed in ~/ghq/ may be anything, like my public repo, my private repo or other's public repo (just looking at).)
• I can sync the working state between devices, using push/pull mechanism and working branch.
• Here, 'working state' is repos which I am working on, and working branches which I'm creating temporary commits in.

• Using 3rd-party automatic file sync (like Dropbox) may break local repos.
• Using tools like rsync is troublesome, and lack of collision fixing.

[yasuo-ozu]

I think working directly on ~/ghq/ is enough considerable, but someone may have different opinions.
If there is any other way (or reason why this example is unsound), please let me know.

[DrumRobot]

Thanks for this PR! The use case of managing ghq root as a git repository is valid. However, I have some concerns about the current implementation and would like to suggest an alternative approach.

Concerns with Current Implementation

Default Behavior Change

The PR changes ghq get to automatically detect if inside a git worktree and use git submodule add. This could lead to unexpected behavior:

cd ~/my-project  # happens to be a git repo
ghq get some/repo  # unexpectedly adds as submodule

Suggestion: Opt-in --submodule Flag

Instead of auto-detection, consider an explicit flag:

ghq get --submodule https://github.com/user/repo

This is:

• Predictable: User explicitly chooses submodule behavior
• Safe: No accidental submodule additions
• Consistent: Follows the pattern of other flags (--bare, --shallow)

Related Feature: --worktree

I've opened #428 proposing a --worktree flag and created a proof-of-concept PR #429.

Flag	Use Case	Repository Structure
--submodule	Manage repos as part of parent git repo	Parent controls child commits
--worktree	Sync bare repos via file sync tools	Independent repositories

These two features could complement each other nicely. Would love to hear your thoughts!