Thanks for the additional clarification on detached vs orphan. I want to thank you guys again for being so patient and helpful. It helps a lot, as for some reason, only reading the docs doesn't seem to sink in as fast as I would like ;-) Regarding the usage of an orphan branch, a coworker of mine suggested an alternate way, which seems similar to me regarding the result, but if you could take a look at it and tell me what you think, that would be very helpful: 1) On the public server, init a blank repo, and commit there an export of the public tree as initial import. 2) On the devel machines, use git-remote to track that repo's master as a local 'public' branch. That public branch now has no history other than the initial import, and is in the same repo as both my private branch and my public-branch-with-full-history (not to be used for future work). 3) From there, use this 'public' branch as if it was created using --orphan from my local public-branch-with-full-history. Are there any essential properties that set apart a 'public' branch created this way from one creating using your suggested --orphan method ? On Thu, May 5, 2011 at 11:10 PM, Seth Robertson <in-gitvger@xxxxxxxx> wrote: > > In message <BANLkTikFdV=nGW-L+3NVzP58uPiS5ui-9A@xxxxxxxxxxxxxx>, Jerome Martin > writes: > > One thing I do not understand clearly is why with a detached (I guess this > is synonym to orphan ? At least when creating it ?) branch cannot be then > merged with the branch that was initially copied to create it and just get > the additional commits. Instead, it gets the whole history. Being used to > using merge between my public/private branches, I am afraid that using that > orphan branch might lead to disaster eventually. > > Junio appears to have answered much of these followup questions so I > will focus on a slight misunderstand you exhibit here. > > An orphan branch is very different from a detached head. A detached > head is not on any branch. Commits on detached heads cannot typically > be referenced by any symbolic name and will eventually go away through > garbage collection. In general you want to avoid detached heads for > any read/write activity. > > An orphan branch, on the other hand, is one which simply doesn't have > a parent. The first commit you make in a new repository is also > orphan, though it is not talked about as such. The point of this > orphan branch is that since it does not have a parental link from your > private branch, if you publish the orphan it will not bring along any > of the private commits. > > As Junio stated/suggested, as long as you are careful to never merge > from private into public, and instead either cherry-pick or do > development from public and merge that into private, you should be > safe. However, a good safety test might be to have an intermediate > repository be part of your public push process, and have a > post-receive (or other process) script run which looks for magic > cookies in that intermediate repo showing that private data has leaked > before proceeding to push that validated repo to a publicly accessible > repo. > > -Seth Robertson > -- Jérôme Martin -- 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