tags:

views:

85

answers:

3

I have two versions of one project in one local git repository. I have to commit this repository into 2 remote repositories, one for each version;

LOCAL GIT(V1/V2) -> REMOTE GIT(V1), REMOTE GIT(V2)

I have some files in the LOCAL GIT repository which should only go to REMOTE GIT(V1) and other should only go to REMOTE GIT(V2). Now I commit full local repository to both remotes. Can I only commit some files to REMOTE1?

I need to have both version of the project in one repository, but would like to have an options to divide history a bit. I do not think that any branching can help as then I would have to make the same changes to both branches mostly. Most of the code, 90% of the code is the same for VER 1 and VER 2. New code is usually the same for both versions.

A: 

Sounds like you need to be using submodules git-submodule. You would store the common code in the main repository, but then store the separate versions in submodules. You can't split history with git. Each commit is cryptographically based on content and parents.

Rob Curtis
submodules are for embedding another project in a foreign repositories at some location in your source tree. The OP has only one project (with different branches) so submodules are not relevant.
Wim Coenen
+3  A: 

Branching is exactly what you need. Branching is easy and very quick with Git, so you don't lose anything but a few more keystrokes.

You can use 3 branches. Create a "common" branch where you'll work on stuff common to both "forks" and merge into them after commits. For specific stuff, work in one of the branches.

Git uses hard links on the filesystem so branches are cheap both in terms of speed and used space.

Finally, you can always select which branch to push/pull.

Milan Babuškov
Branches aren't cheap because of "hard links". Branches are cheap because the branch is just a commit, which refers by SHA1 id to all of its parts, and the same file in different commit trees will have the same SHA1, and be stored only once.Now, SVN, on the other hand, stores branches by having entire directory structures, and *does* use hard links to optimize that. Please don't confuse old, ugly SVN, with new slick git.
Randal Schwartz
Thanks for the correction, I fixed it now.
Milan Babuškov
@Randal: SVN doesn't use file system hard links either. A branch in SVN is also cheap because it is "just a commit". The only difference is that in SVN cheap file/folder copies, branches and tags are all made by the same mechanism, while in git branches are a separate concept.
Wim Coenen
A: 

Create three Git repositories: core, app_1, app_2. Within each of the app repositories, create a Git submodule referencing the core repository.

Treat the core repository as a pure library and the app repositories as pure library consumers, structuring the three projects such that you can keep everything common to the two "versions" in the core repository and everything that would diverge between the two versions in the app repositories. Structure the app repositories such that the core project can be placed wholesale, with no modifications, into a subdirectory within the app repositories. You may require a minimal common initialization script shared between all app repositories, but that is a small price to pay.

The scenario of structuring the code this way is very common. Although using Git in this way to support this code architecture scenario is far less common, it is seen as a viable possibility.

Justice