Hi Philip, > This has the developers having a full copy/history of the integrators > relevant branches, so that when the pull of the developers branch occurs > there is a proper link to the integrators history. True. > > There are other ways to create a branch which has all the developers feature > history removed, rather tha using an --orphan, which removes the integrators > history as well. The topic branches are populated only by the developers. The integrators merge all the topic branches into branches dedicated to the integration. In case of need, the developers can pull these (with all the integrators' history). > > The disconnection of the D' source branch makes it sound like you have a > second SCM system that you have to put stuff into, which is independent of > the development teams git repos. I have this [hassle] at my $dayjob -one > almost has to hide git from the powers-that-be. Well, there is another way to see this: think to a distributed SCM in which there are some parts of the contents that are shared and some that are not. The technique to use disconnected branches is only a way of implementing this. If, say, git push had an option to filter out the binaries there would be no need for disconnected branches. > > A reasonable solution. You can also create a sentinel (--root) commit for > any time that you need to create the source branch, just so it (the real > source code commit) has a different parent when on source branch to that on > the binaries branch. Do you mean I could create an empty root commit to be used as parent for the real source commit? Or that there is some --root option to be used? -Angelo -- 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