From: Claus Schneider <claus.schneider@eficode.com>
Date: Fri, 29 May 2026 12:35:34 GMT
Subject: Re: [PATCH 0/5] git son: add command to create independent child repositories
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:
>
>
> > 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.