2

We're working on a big project here at work with feature "bundles" (EDIT: "bundle" is just a term we use internally to refer to a specific functionality package, and isn't meant as a git term) spread out into several different git repositories. I'm getting ready to send a batch of changes upstream for review and testing, but I've run into a snag trying to get everything to play together nicely.

What I've done so far is clone from the repo containing the code bundle into my main project, which works insofar as it gets the files where they need to go. However, when I go to add/commit and push, the files from the "bundle" repo won't go with it, presumably because they are part of a different git repository than the one I'm pushing from.

It's not really a viable option to ask all the other developers on the team to pull in my "bundle" every time it changes (especially since it's still somewhat early in the dev cycle and sees a lot of revisions and refactoring), and I don't really want to copy the files by hand every time I need to send them up, either. Preferably, I'd be able to set things up so that I could pull from my "bundle" repo into my main repo, then push the changes as a whole.

Is there a way to do what I'm looking for with git?

Problematic
  • 17,567
  • 10
  • 73
  • 85
  • What do you actually mean by “bundle repository”? Are you using the `git bundle` command to transfer objects instead of normal bare repositories? Or maybe you are using Git submodules? If so, how to your “bundles” relate to submodules? – Chris Johnsen May 17 '11 at 03:06
  • Bundle is just a term we use internally; it's got nothing to do with git. I'll edit my question to reflect that. – Problematic May 17 '11 at 03:26

3 Answers3

2

I'm not getting a clear picture of what you want (the usage of the word bundle seems non-standard here?); However,

  1. man git-remote might be what you need
  2. git push --mirror (perhaps starting with a git clone --mirror
  3. If you want the inverse (track all remote branches in a local repo), see my recent additions here: "fetch --all" in a git bare repository doesn't synchronize local branches to the remote ones
Community
  • 1
  • 1
sehe
  • 374,641
  • 47
  • 450
  • 633
2

Yes, you can do it using forking.

Here is some tutorial how to fork a repository and make basic actions you need: http://help.github.com/fork-a-repo/ (GitHub help)

And here you can find something more about remotes (this feature is used to work with forks): http://help.github.com/remotes/

Tadeck
  • 132,510
  • 28
  • 152
  • 198
1

Your description is still not perfectly clear to me, but it sounds like you might need to use a submodule, a subtree merge, or git subtree (a “third-party” tool).

You should probably ask around your project to see if there are plans in place for how to handle this kind of situation. Someone may have already planned how to integrate content from the “bundle” repositories into the rest of the code in the “main” repository.

Submodules are the standard way to publish a link from one repository to another (using special “gitlink” tree entries and data in the .gitmodules file). The use of submodules allows other users to reestablish the repository-inside-repository setup that (it sounds like) you created locally during your development.
Using submodules will require some workflow changes for any other people that need to access them (i.e. git submodule update (with --init the first time) to make sure they have the right commit subrepository commit checked out after updating (e.g. pulling into) the “main” repository).

A subtree merge is a way of directly incorporating the content from an unrelated commit (e.g. from the repository of a library) into a subtree (subdirectory) of your main project. Only the users that need to pull in (or push out) updates to the content under the subtree actually need to do anything differently (e.g. they can use git merge -s subtree to merge in updates to the source history). Some people dislike subtree merges because it incorporates (“pollutes”) the main project’s history with a copy of the subtree’s history.

The git subtree tool (a third-party tool) can help manage normal subtree merges. For example, the git subtree split subcommand can take commits made atop the main repository’s history and rewrite them so that they appear atop the subtree’s original history. This makes it easy to make “local” changes to the subtree content and later push them “upstream”. It also has a --squash mode that offers much of the benefit of a normal subtree merge while preventing the history “pollution”.
The author of git subtree has linked to a tutorial that seems fairly useful.

Chris Johnsen
  • 214,407
  • 26
  • 209
  • 186