RFC: commit-to-branch

[Martin Pool]

On Mon, Dec 1, 2008 at 3:29 PM, Robert Collins
<robertc at robertcollins.net> wrote:
> I'd like some feedback on UI for committing to a different branch.
>
> Firstly the use case - in a loom one often prepares work that belongs on
> a different lower thread[branch].

I think this would be a useful thing.

This connects a bit to the other thread "thread names in urls"
(originally about bzr-git.)

> The slow way is:
> bzr switch actual-thread
> bzr commit files-to-commit
> bzr shelve --all
> while not-on-the-original-thread up;bzr commit
> bzr unshelve --all

I guess you meant "while bzr up-thread; do bzr commit; done" ?

> I'd like this to be a single command for convenience.

It's easy to see what should happen if the other thread is currently
on the working tree's basis revision (or equivalently is being
implicitly created by the new commit.)  Perhaps only supporting this
is enough for now, though you seem to be going beyond it.

If it's elsewhere, there seem to be two issues. Firstly, there's an
implicit merge going down to the thread; what happens if that
conflicts inside of commit?  Secondly, what if you actually want to
commit (or at least merge) some files that are not modified in your
original tree.  That seems quite likely.

This is the kind of case where building up a git index indicating what
you want to commit, separate from the working tree, can be useful, but
that's a usability shambles for other reasons.  Possibly your 'marks'
idea is better.

I think the changes to enable this could probably only be good for the
commit code but I'd hesitate to merge it unless we can clearly explain
eg in the user manual how these things work.

To look at this another way: the working tree is a good place to carry
uncommitted changes and to deal with any problems that come up.  So
why can't your example be simplified to

  bzr switch PLACE_TO_COMMIT
  bzr commit ....
  bzr switch ORIGINAL_THREAD

This would still carry across the uncommitted changes; there's no need
to shelve them.  However, you would end up without having merged from
the original thread, and therefore the changes would actually have
been removed from your working directory.

If it's a change that you don't actually need in your original thread,
eg a documentation correction, perhaps it's actually preferable that
it's kept separate.

If you do need it there we need the merge (and possibly resolution) to
be done, without conflicting with your current work in progress.
Since we just took the changes from this tree, they _should_ reapply
with no conflicts, although there are realistic cases where they
won't, if you did a selective commit or already resolved conflicts.

It would be generally useful to have a 'merge, and if there are no
conflicts commit' option, which you could do after switching back, and
that in turn could be an option to 'switch': switch to this thread or
branch, and bring across my work.

What I just described would generate just one merge between the
relevant threads, not merges all the way up the loom.  I'm still
skeptical about the idea they should always be merged up in a stack,
rather than having just the necessary merges.

-- 
Martin <http://launchpad.net/~mbp/>