Junio C Hamano <gitster@xxxxxxxxx> writes: > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > >> On Fri, 17 Aug 2007, David Kastrup wrote: >>> >>> But it isn't an independent git project: the superproject has its >>> _own_ copy of dsp, with its _own_ specific commits and fixes that are >>> not supposed to ever end up in the dsp "mothership". >> >> Sure. And that's different from any git "branch" exactly how? >> >> So you'd have different branches in the superproject - the way you always >> have when you have two copies of a git project. And then you merge between >> the two at will. > > My reading of the project David is talking about is that its dsp > project which is a "subproject" part gets non generic commits within > the context of the superproject --- which means (1) you would have > branches in the subproject not superproject, and (2) once you did > that, the subproject is not really a subproject anymore, as you > cannot merge that back to the standalone dsp project without > dragging the non-generic bits along with it. Ok, I should perhaps should not make things harder than they are: the superprojects, being particular to one customer each, don't really branch (except that git-svn makes a git branch from every Subversion tag). The subproject is the one that has considerable branching and merges. What usually gets pulled into the superproject is a copy of a stable subproject branch. Once this copy is in, only fixes (from the stable branch) or features (from the development branch) that the customer definitely needs are merged into the superproject. While there might happen some subproject work in the customer branch, this mostly happens during bugfixing for the customer, and the changes are typically pulled back into the subproject proper at some point of time. Inside of the subproject tree, there is really no superproject _development_ going on. >> There's a special "subtree" merge that does exactly that: it >> basically is the normal recursive merge, except it merges into a >> subtree. I think that's how Junio does the "git-gui" merges. Junio? > > Yes. It has exactly the same semantics and limitations with the > gitk merge, but just merges into a sub directory. Shawn cannot > easily pull the changes done inside git.git repository back to > git-gui.git proper. Well, the other direction would be the most important one: merging or cherrypicking selected changes in the subproject branches into the superproject copy of the subproject. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
