From: Jerome Martin <tramjoe.merin@gmail.com>
Date: Fri, 06 May 2011 09:27:11 GMT
Subject: Re: Private/public branches/repos workflow
Message-ID: <BANLkTikC23_hi4TppxdfMjCZDJWNd9ZF7g@mail.gmail.com>
In-Reply-To: <7vk4e44gfo.fsf@alter.siamese.dyndns.org>

Again, thanks for the help :-)

On Fri, May 6, 2011 at 6:10 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jerome Martin <tramjoe.merin@gmail.com> writes:
>
>> Could you tell me how you would see usage of rebasing inside the
>> workflow you describe ? I am thinking about features (mistakenly)
>> implemented on top of the private branch that need later to be release
>> in the public branch. Can this be the shortcut to avoid lengthy
>> cherry-picks ?
>
> Mistakes and changes of plans can happen, but it's not a big deal.
>
> In the git project itself, even the "master" branch that corresponds to
> your "private" branch is managed with topic branch workflow, so it is
> entirely possible that a topic that was originally meant only for the next
> release turns out to be better backported to the maintenance track.
>
> If you have a private "feature-A" topic with many commits:
>
>                     O   public
>                      \
>  ...---x---x---x---X---S  private
>                        \
>                         a---b---...---z  feature-A
>
> and later it turns out that it is better to release them also to the
> public, instead of cherry-picking the commits to the public, you could at
> that point do something like this:
>
>    $ git checkout -b public-feature-A feature-A
>    $ git rebase --onto public private
>
> which will first create a new branch "public-feature-A" that points at the
> same tip of "feature-A", and then rebases the commits on that branch that
> were made since the topic was forked from "private" on top of the tip of
> the "public" branch, resulting in:
>
>                       a'--b'--...--z' public-feature-A
>                      /
>                     O   public
>                      \
>  ...---x---x---x---X---S  private
>                        \
>                         a---b---...---z  feature-A
>
> and then you may choose when to merge that to the "public" branch.
> By the time you do this, perhaps the original "feature-A" may have already
> been merged to "private" after fully tested and audited, like this:
>
>                       a'--b'--...--z' public-feature-A
>                      /
>                     O   public
>                      \
>  ...---x---x---x---X---S---x---x---x-----*  private
>                        \               /
>                         a---b---...---z  feature-A
>
> and then after you merged "public-feature-A" to "public":
>
>                       a'--b'--...--z' public-feature-A
>                      /              \
>                     O---o---...---o--*   public
>                      \
>  ...---x---x---x---X---S---x---...---x---*  private
>                        \               /
>                         a---b---...---z  feature-A
>
> merging "public" back to "private" hopefully may have too many conflicts
> between the feature-A and public-feature-A branches, as they are supposed
> to be patch equivalent, to produce this:
>
>
>                       a'--b'--...--z' public-feature-A
>                      /              \
>                     O---o---...---o--*---.   public
>                      \                     \
>  ...---x---x---x---X---S---x---...---x---*---*   private
>                        \               /
>                         a---b---...---z  feature-A
>
> After this you could even garbage collect the two topic branches ;-).
>



-- 
Jérôme Martin