0

I have project example with the following structure:

example
|-- A
|   `-- a.txt
|-- B
|   `-- b.txt
`-- xyz.txt

which I push to my private remote server A. Now I need to make the example/B folder accessible to someone else on a different server.

Is there a simple way to push the folder example/B to a different remote B, without pushing the whole project B? Additionally it shouldn't interrupt my normal workflow, if I change anything in b.txt it needs to be pushed to A too.

greole
  • 4,523
  • 5
  • 29
  • 49
  • From the question, you're used to working with svn. No, there isn't a simple way - you'd use e.g. [git subtree split](http://stackoverflow.com/questions/359424/detach-subdirectory-into-separate-git-repository) to create "repository B". – AD7six Sep 17 '15 at 13:44
  • Do you need `B` to be a git repository as well, or would it be enough to just copy the current state of the files to some other server? If the latter is enough, simply use `rsync`. – Sven Marnach Sep 17 '15 at 13:46
  • @SvenMarnach `B` should be a repository to, so that changes can be logged. – greole Sep 17 '15 at 14:51
  • @AD7six Splitting means that I have to manage two separate repositories at the end, but is an integral part of my project and should be imported as `submodul` to another project. – greole Sep 17 '15 at 14:57

2 Answers2

1

You have a couple options, though each is going to introduce some overhead.

Git submodules

No one really likes submodules, but they're in Git for this purpose. Split example/B into its own repository, remove the directory from example, and then re-include the example/B repository as a submodule of example.

Once that's done, you'll be able to commit to the example/B repo and push to server B without the rest of the project. example won't contain the changes until you update the submodule.

Fake submodules

People call it fake submodules, but really it's just nesting one repository inside another. Get into example/B and run git init to create a brand new repo. Git looks for .git/ in your current directory first, then walks up the parents, so when you're in example/B, Git will operate on the new repository, and when you're in example, Git will operate on the original one. Like before, now you can commit to example/B and push it to server B without the rest of the project.

The difference between this strategy and real submodules is when you navigate back up to example, you have to commit the change again to the main repository.

Other ideas

If example/B is independent enough to be interesting to server B without the rest of the main project, maybe it shouldn't be part of the main project at all. Maybe it makes sense to split completely into its own project and then include it as a totally external dependency of the current one.

Kristján
  • 18,165
  • 5
  • 50
  • 62
0

Make a link in the filesystem someplace else to example/B, git init and connect it to that other destination (as a remote).

It's not git'ish, but pragmatic, I guess. That way your "main project" doesn't know anything of that other git repository (the .git folder would have to be somewhere in a parent folder, not in example/B directly).

cslotty
  • 1,696
  • 20
  • 28