Comment 2 for bug 780742

> I also don't understand why you're doing merge -i. Is that to select only the changes in the unit tests?

Yes, that's right. In practice I usually commit the changes intended for $OTHER on $ORIGINAL, switch-pipe $OTHER (thus leaving the uncommitted work-in-progress), and then merge from $ORIGINAL. But to avoid wading through unrelated files with "-i", I end up shying away from making other commits on $ORIGINAL, which isn't positive.

> Would merge pipe/path/to/files work?

Although that would be generally helpful, it wouldn't help my actual situation.

To expand on the background, the motivation behind "commit --to-pipe" is to avoid having to use switch-pipe. I use Eclipse (though I do everything from the CLI rather than use bzr-eclipse). Because Eclipse has a long startup time, I don't close it when switching pipes. Eclipse does a great job of picking up any changes to the file system, but it doesn't much like it the directories corresponding to an open project disappears (a project = a directory with some special Eclipse files for tracking state). This situation happens when I switch to the second-level pipe (containing my app hacks) as the unit test projects are removed. Eclipse notices the unit test projects have disappeared and creates new project directories, which bzr subsequently flags as conflicts when switching back to another pipe. As a result, the process of moving changes between pipes turns into a much heavier-weight operation than I'd like it be. And it's why "pump --from-submit" is very useful.

I see what you mean about the break with bzr's notion of merge/commit. I'd be happy with a different command name :) But I think it makes sense when a pipeline is instead seen as being tool for structuring a sequence of commits — I'm just amending a commit.