How can I achieve the effect of pulling into a bare repository which isn't a mirror?

Question

I'm trying to set up a repository system which allows projects to share a "framework" remote, so that bugfixes to the framework can be pulled into the projects.

My approach for this is to set up a bare repository at //NAS/projects/base, clone it to a bare repository at //NAS/projects/projectX, and rename projectX's remote from origin to framework to avoid confusion. The intention is that then each developer can clone //NAS/projects/projectX and push their changes back to that repository, and the framework maintainer can clone //NAS/projects/base and push their changes back to that repository. Then projectX can pull from base - and here my approach falls down because I can't pull into a bare repository.

There are existing questions about setups which seem superficially similar but on inspection appear to address only the case where the second bare repository is a mirror of the first. That isn't the case here: I want to be able to create a projectY which also uses the framework and gets its changes but without any code specific to projectX or projectY ending up in base.

How does git support this kind of structure? Does someone need to add base as a remote to their local repository, pull from it, and then push into projectX? I can fetch from base into projectX: is there some command I can then do to rebase its master to the HEAD of base's master? Or am I going about this in completely the wrong way?

Answer 1

Short answer: You will need to have the project owners fetch from base to their local (non-bare) repository and merge the bugfixes/updates from base into their projectx/master branch (or rebase their master onto base). From there they can push the updated projectx state back to the server for everyone else to use. (See git merging branches in a bare repository)

If I understand correctly, base is like a base class in an OO hierarchy, and the projects are like derived classes, automatically inheriting the changes to base, but implementing some things differently, correct? Otherwise, if it's more of a "base library with framework functions" type of situation, the way to go would be a seperate project that gets referenced (e.g. via submodules) by the other projects, as the comment under your question suggests.

What you seem to want is a sort of automatic bugfix integration from base into the projects, all in the bare repos on the server. This will not work, as git indicates with the error messages for merge/rebase ("This operation must be run in a work tree"), for a simple reason: Even if it could merge inside a repo, git can't guarantee there won't be conflicts during the merge (perhaps somebody already applied a different bugfix at the same location), and to resolve the merge conflict, you need to edit the affected file(s) by hand, for which you need a checked out working copy. Even if there are no conflicts, git would have to create a "temporary" working copy to apply the changes in and then commit it again. This is not how git works: The repo is only a collection of (compressed) snaphots of the project state at one point in time. You only add new snapshots to it, you don't modify the ones already inside. (Fetching into the bare projectx remote (as opposed to pulling) works because this only copies complete blobs and refs into the repository to make the fetched remote branches available, but does not modify existing ones.)

If you want a mostly automatic solution, you could employ a shell script that periodically fetches from base, merges the updates into the project, and pushes the updated project master to the server, if no merge conflicts have occurred during the process. I'd advise against this, though, as you will have problems if a "functional" conflict arises that isn't caught by the merge, in which case you'd have to stop the automatic script for as long as project is incompatible with the new changes from base. Depending on the likelyhood of this to happen, proceed with caution (in an unstable_updates branch or something).