Again, thanks for the help :-) On Fri, May 6, 2011 at 6:10 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jerome Martin <tramjoe.merin@xxxxxxxxx> 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 -- 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