Re: [PATCH 0/5] git son: add command to create independent child repositories

From: Claus Schneider <claus.schneider@eficode.com>
Date: May 29, 2026, 12:35 UTC
Message-ID: <CA+GP4bqNrnER14GaxOSPdQCO0HFJzv6Kjo6VVFhr=KredVu0jw@mail.gmail.com>
In-Reply-To: <7377E3A2-C866-4E3D-85FC-BC6E10CBF8FC@gmail.com>

Hi ..

I would motivate to fix in git-submodules in stead. I updated the logic around the ignored setting of a submodule, so it is truly ignored - both in git status(already) and `git add`, which now explicitly requires `--force`. It now gives the ability to configure your submodule as 'loosely' by tracking branches without the friction of `git add` is staging it all the time and you get conflicts in PR/integrations. You can use git submodule status to list the sha1 of the submodule for release etc.

https://github.com/gitgitgadget/git/pull/1987 alias "git-add: Skip submodules with ignore=all unless --force and explicit path used by bicschneider · Pull Request #1987 · gitgitgadget/git"

Please try this update and then describe what is ( still ) missing as i am looking into submodules in general and will try to "fix" the friction points of developers.

Best regards Claus Schneider

On Tue, May 26, 2026 at 11:29 PM Ben Knoble <ben.knoble@gmail.com> wrote:

Show 28 quoted lines

>
>
> > Le 26 mai 2026 à 13:08, Evan Haque via GitGitGadget <gitgitgadget@gmail.com> a écrit :
> >
> > 
> > Motivation
> > ==========
> >
> > When spinning off a new project that is related to an existing repository,
> > there is no built-in way to create a child repository that maintains a link
> > back to its parent without the tight coupling of submodules. Submodules pin
> > the child to a specific commit and require the parent to track the child in
> > its index, which is too heavyweight when the child is meant to be fully
> > independent.
> >
> > The typical workflow today is manual: git init, git remote add, update
> > .gitignore — three steps that are easy to forget or get wrong. git son
> > automates this and establishes a lightweight convention for the parent-child
> > relationship: a remote named parent in the child, and nothing in the parent
> > except an ignore rule.
>
> I don’t really understand the motivation, but if your goal is to create another repo with the current one as a remote, how does something like
>
>     git clone . child
>
> help you? (I’m pretty sure you can even set the remote name to « parent » if you wish.)
>
> You also didn’t mention worktrees or subtrees, which might be useful for you.