All of lore.kernel.org
 help / color / mirror / Atom feed
From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: USA Linux UAE <usasoftwareengineer@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: Managing one github repo with Gitignore and Submodules for two different remotes
Date: Thu, 6 Feb 2025 22:23:39 +0000	[thread overview]
Message-ID: <Z6U2a0l0kX0MmNFN@tapette.crustytoothpaste.net> (raw)
In-Reply-To: <CAOXJ2J-StZYg4E9eGug=wHNjBu3aPdoy0x17aS9jLn14SyfJkA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]

On 2025-02-06 at 14:10:44, USA Linux UAE wrote:
> Hi everyone,
> 
> I'm hoping to get some advice on managing a GitHub repository with a
> slightly complex setup. We have a main repo that utilizes both a
> .gitignore file and submodules. Our goal is to push this repo to two
> different remote repositories (let's call them remote_A and remote_B),
> but with a key difference:
> 
> remote_A should respect the .gitignore file as usual, excluding the
> files and directories specified within it.
> remote_B should effectively ignore the .gitignore file, and include
> all files and directories, even those listed in .gitignore.
> Essentially, we want the opposite behavior of .gitignore for remote_B.

Unfortunately, there is no easy way to do what you want because you
essentially have two separate, independent, and diverging histories.
Git doesn't offer functionality to push only part of the history, and
`.gitignore` is honoured when files are added, not when pushing.  Once
files have been added, `.gitignore` has no effect.

> Additionally, we need to ensure the submodules are handled correctly
> for both remotes. Ideally, the submodule pointers should remain
> consistent, regardless of which remote we're pushing to.
> 
> 
> Could anyone offer advice on the best approach for this scenario? Are
> there any recommended workflows or tools specifically designed for
> this type of setup? Any insights regarding submodule management in
> this context would be greatly appreciated.

The best way to do what you want is to put the extra files from the
second case in a separate submodule, which can be pushed to server B but
not server A.  You may want to add a script to handle the case where
they do or don't exist and place them in the proper place via copy or
symlink if they're present.  You'll want to ignore them in the main
repo, though, since you don't want them to be checked in accidentally.
-- 
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

      reply	other threads:[~2025-02-06 22:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-06 14:10 Managing one github repo with Gitignore and Submodules for two different remotes USA Linux UAE
2025-02-06 22:23 ` brian m. carlson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Z6U2a0l0kX0MmNFN@tapette.crustytoothpaste.net \
    --to=sandals@crustytoothpaste.net \
    --cc=git@vger.kernel.org \
    --cc=usasoftwareengineer@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.