threads / discuss / 54996

Repository of repositories without submodules?

Subject: Repository of repositories without submodules?

## tl;dr

2 messages between Jan 16, 2021 and Jan 16, 2021.

replies: 1people: 2as markdown or json

Chuck Ricketts· Jan 16, 2021, 10:39 UTC · lore

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
Manuel Reimer· Jan 16, 2021, 14:01 UTC · re: Chuck Ricketts · lore

Re: Repository of repositories without submodules?

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

← back to recent threads