RFC: commit-to-branch

[Robert Collins]

On Mon, 2008-12-01 at 17:33 +1100, Martin Pool wrote:
> 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.)

It does, but not in any really new way - bzr switch already has 'an'
answer to this as switch only works within looms. I think though we have
enough experience to triangulate on a interface for it now.

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

Yah, though its now able to be 'bzr up' :).

> > 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.

Implicitly creating would be nifty; I'd like a new option for *that* to
avoid tedious typo-cleanups. Unless we can make it trivial to rollback
or ask for input or something.

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

As I described, it would be equivalent to doing 'bzr merge
--uncommitted', so if it conflicts, I would expect it to fail. There is
always the manual approach to make it work. It would not be at all
equivalent to merging the two threads together, in what I proposed.
There is a use for that though, but I'm not sure its really important,
because, if you have *this current* proposal, then you don't have stuff
accumulating in the wrong thread, you can always be committing to the
correct thread.

>   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.

As above, I don't think it is. I'd like to try this as simply as
possible though, which is to say that 'this is not a regular merge or
even a cherrypick'.

> 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 marks would play well with this for selecting what is committed.

> 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.

Actually no. You would not have merged across from the original thread
(switch down un-merges, and switch-up re-merges). You also would have
*lost* the changes you committed - they are now in the lower thread, and
were reverted by the 'switch ORIGINAL_THREAD' command.

> 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.

Not for the use case of distro packaging where you package everything.
If you wanted a separate branch, I would say you use the same command
but commit out to a different branch (or even a different loom).

> 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.

Neither of those cases should be able to create conflicts in the
proposal I put up. Here is a case that will:
threads:
top
middle
bottom

workingtree/foo:
foo
gam
baz

top/foo:
foo
bar
baz

middle/foo:
foo
quux
baz

bottom/foo:
foo
bar
baz


merge --uncommitted from the working tree into bottom will succeed, the
bzr up-thread to middle will fail because there are two changes made to
the line bar - one to gam, one to quux.

> 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.

Perhaps. It certainly wouldn't do what I have in mind, which is an
all-in-memory fast alteration of the loom state, with no expensive disk
changes at all.

> 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.

The current design's lower level machinery support both; however, you'll
get the best results if you have them merged in a stack, because you
make conflict resolutions once, and no magic is involved - its all
transparent and visible to the user.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20081201/28cc424e/attachment-0001.pgp