thanks! and a tiny comment

[Yaroslav Halchenko]

On Wed, 24 Oct 2007, Sam Vilain wrote:
> Or, make a new branch at the point that the unwanted feature branch was
> merged in, and then rebase all of the changes that you do want on top of
> that.  This represents what happened perfectly.  You archive the removed
> history somewhere like refs/Attic/remove-feature.
indeed... having stored "old" evolution of the branch somewhere (in
Attic) resolves the issue of orphaned commits/tags. 1 side effect seems
to be that that build branch history becomes quite non-linear... though
probably it is not a problem at all...

> If people are unable to harden up sufficiently to handle history changes
> like this, another option is to make a single ("squashed") revert commit
> that undoes the changes, and make sure that the *new* feature
> development branch is rebased on top of *that*.  ie, the revert commit
> is then reverted again and development on the feature branch continues.
I like to have the feature branches be based on upstream branch, so I
can't rebase it on top of build branch (or have I read this paragraph
incorrectly?)



-- 
                                  .-.
=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]