Repository of repositories without submodules?

Repository of repositories without submodules?

[Chuck Ricketts]

I am cross-compiling many Arch packages with small changes made
locally in order to better suit a cross-compiling environment. That
being said, I've got a directory of single-directory git repos that I
would like to publish my changes to.

I ran into more than a few snags trying to figure out how to do this.
Firstly, no matter what, if git sees a directory in the repo with a
.git file or folder, it automatically classifies it as a submodule --
no questions asked. Of course, as submodules the contents aren't able
to be pushed (so far as I can figure out, anyway) because, I presume,
the assumption is that they're able to be retrieved at an alternate
location.

In my project, this leads to a few issues:
1) My local changes will not be pushable without pushing the whole
origin repository upstream to another location. I guess I could try to
strip down the history to only a few files to make it more manageable,
but in the end there might be a hundred or so different repos.
2) The changes I have made are very small, especially when compared to
the size of the repositories that those changes are based on --
pushing the origin repo upstream is potentially wasteful even given
options from #1.
3) Using the submodule method I would have to originate every
subdirectory as a separate cloneable repo just to get them organized
into a directory structure that makes sense. Of course, each repo is
going to have to be managed separately, which adds tremendously to
project overhead if it's a public repository (which I plan it being).
Of course, that's no to mention the potential nightmare of having to
keep those submodule references updated.

In my eyes, it would be so much simpler to tell git "Hey, I know these
are repositories, but just ignore that, mmk?" This way I can still
manage each folder as a separate repo for merging upstream changes,
etc. and I don't have to deal with any of the other issues.

I bypassed this issue by bare cloning all of the separate repos into
an ignored subdirectory. Then, I used worktrees to check them out to
the locations where I want them. And, finally, I had to use some shell
scripting hackery to create and destroy the .git file in each of the
subdirectories as I move around so that when I go to add files for
commit git doesn't think it's a repo and treat it like a submodule
against my wishes.

I mean, it works, but it doesn't seem like a good, correct, or
especially sane way to go about it. Surely I've missed something?

Chuck Ricketts

Re: Repository of repositories without submodules?

[Manuel Reimer]

On 16.01.21 11:39, Chuck Ricketts wrote:
> I am cross-compiling many Arch packages with small changes made
> locally in order to better suit a cross-compiling environment. That
> being said, I've got a directory of single-directory git repos that I
> would like to publish my changes to.

Seems like the common "several directory GIT" case caused by the fact 
that AUR organizes all PKGBUILDs in separate repos.

For me "git subtree" works great for this case:

https://github.com/M-Reimer/PKGBUILDs
or
https://github.com/M-Reimer/wine-lol

See the "pkg.sh" file which, to be honest, isn't even from me. I just 
adapted it slightly to my use case. Original came from here:

https://github.com/yuvadm/archlinux-packages/blob/master/pkg.sh

Every single PKGBUILD is its own "subtree" which can be pushed 
separately to AUR if I want to. Pushing this subtree makes GIT somehow 
"automagically" figure out a proper commit history for this subdirectory 
and push this to the external repo.

Manuel