Re: Private/public branches/repos workflow

From: Jerome Martin <tramjoe.merin@gmail.com>
Date: May 5, 2011, 22:05 UTC
Message-ID: <BANLkTinwuGTbX0qeOZHAhGKgZzPBTTaHCw@mail.gmail.com>
In-Reply-To: <201105052110.p45LAViP010495@no.baka.org>

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@baka.org> wrote:

Show 39 quoted lines

>
> In message <BANLkTikFdV=nGW-L+3NVzP58uPiS5ui-9A@mail.gmail.com>, 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