1

I've been accumulating related experiments in a directory structure and as I go, I create a gist so I can demo the experiment on bl.ocks.org.
When I create the gist, I add it as a remote for the subfolder's repo. That way I can include checking the bl.ock in my iterations by pushing to the remote (gist).

The result is a directory tree with lots of repos in it and these individual repos sometimes have multiple branches. Also, some of the subfolders are not repos.

Now, I want to consolidate the experiments in a master github repo. So i created a repo on github, set it as the remote, pulled merged etc., and then pushed.
All of the non-repo folders pushed ok, but all of the folders in the tree that contained a .git folder did not push properly: they are there in the github repo but they are "greyed out". I recognise this from when I have a repo with multiple branches where folders that do not exist on the selected branch are "greyed out" in the same way: presumably this is github's way of representing empty folders.
enter image description here How can I handle this? I understand that I can't have multiple branches at a subfolder level... do I need to create branches in the master repo by merging one of the branches in the subfolders? How is this meant to work?

I would have thought that git would just push the current checked-out state of the subfolder repos and look towards the root for gitness... thus, the subfolders would not be treated as repos from the perspective of the parent.

Is there a way that I can integrate the subfolder branches into the new structure for example?

Community
  • 1
  • 1
Cool Blue
  • 6,438
  • 6
  • 29
  • 68
  • what do you want to do if those git subfolders get updated by their authors? – Jason Hu Sep 28 '15 at 19:29
  • @HuStmpHrrr, there are no other authors, its just my experiments and proofs of concept. What I want to happen is for github to just store the contents of the folders that are repos, including all of their git state, without interpreting them as repos. Then, I can pull the master branch if I need to rebuild the file structure including all of the git data for the included repos. – Cool Blue Sep 29 '15 at 02:21

1 Answers1

0

Greyed out folders (the "folder in a folder" icon) represent Git submodules, actually. What it sounds like you want to do is not to have submodules (which each depend on their own origin repository), but just to consolidate all the individual repositories into one master repository and then delete all of them.

Git isn't really built to version nested Git repositories except for submodules. The easiest way to merge the repos would be to back up the .git folder in each individual repo, remove it, and then start fresh, i.e. commit every sub-repo's latest commit's working directory into one new commit. Alternatively if you want to keep history, you could merge each of the repositories into the master repo by using one of the methods described in this thread.

In any case, you've got submodules right now and you don't want them, so the general idea is to figure out how you want to structure your repo without having a sub-repository structure.

Maximillian Laumeister
  • 19,884
  • 8
  • 59
  • 78
  • Can you explain how git works exactly when it encounters a .git folder in a sub folder during the push process? – Cool Blue Sep 28 '15 at 23:50
  • @CoolBlue I wish I could, but it's not something I've done before! What I can tell you though is that whatever is going wrong is likely happening during the commit process, since the push process doesn't really modify anything, it just (in essence) syncs your local commits up to GitHub. – Maximillian Laumeister Sep 29 '15 at 00:41
  • Hmm, ok. I find it strange that there is no authoritative conversation or knowledge source about the principles that the algorithms are based on :/ On your second point: but everything works fine in the original, local repos. So that would suggest that the commit process is fine. If the push process works as you say then the remote would work the same. But it doesn't. To me that suggests that the push process is making some choices that filter the structure no? – Cool Blue Sep 29 '15 at 01:18
  • @CoolBlue I have a feeling that if you cleared your working directory and then did a `git checkout master` to restore it, then the files from within the git folders would not be restored. My hunch is that they are not actually committed into git (as files within the main repo or within the submodules), they are just hanging out in your working directory, but I could be wrong. This might be worth putting a bounty on if you still have the problem day after tomorrow. – Maximillian Laumeister Sep 29 '15 at 01:24