thanks! and a tiny comment

[martin f krafft]

also sprach Yaroslav Halchenko <lists at onerussian.com> [2007.10.24.1634 +0200]:
> > 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...

No, it isn't. The one thing I miss though is the GNU arch feature of
freezing that branch. Once we move a branch to the attic, it should
somehow be impossible to commit onto its tip. Ideally, the should
even be a pointer where development continues and Git might even
follow that.

Now, of course, this feature is unlikely to make it upstream because
it would add complications.

> 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?)

Of course you can: the build branch is also a descendant of
upstream...

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
a friend is someone with whom
you can dare to be yourself
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/)
Url : http://lists.alioth.debian.org/pipermail/vcs-pkg-discuss/attachments/20071024/865f1f9c/attachment.pgp