[RFC]: loom: up-thread should 'rebase' if the thread hasn't been pushed.

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> Actually, rebase is the wrong term, but it captures the idea: 'bzr
> up-thread' should do a history edit, like rebase does, when the thread
> that is being moved onto has not been published.
> 
> In a loom, when one does 'bzr record', the tips of the threads are
> captured, much like a bzr tree is captured by 'bzr commit'. With a
> record being done, loom can be [fairly] sure that the contents haven't
> been pushed. Likewise, merge from that loom won't see unrecorded tips or
> threads.

I don't understand what you mean.  I don't know how you're defining
published.  The same thing as pushed?  I don't understand why a record
being done suggests that the contents haven't been pushed.  I would
think that once record has been done, it's very likely for the contents
to be pushed.

If you're thinking of rebasing until "loom record" is issued, please
bear in mind that many loom users, including me, never run loom record.

> My thinking is that by automatically determining whether to do
> rebase-style integration, loom could offer the very lightweight 'your
> commits float' style workflow and seamlessly transition into the 'your
> commits are branches derived-from earlier branches' that is needed for
> merge-preserving history-presentation.

What's the advantage of providing a new 'your commits float' mode?

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko/cGoACgkQ0F+nu1YWqI2s+ACeIgs6z6+OUJMoIrNo+pVZmqtH
5ugAnj5g7fdU8N5lCUpG/nzd2QosIlU3
=s8of
-----END PGP SIGNATURE-----