Provide shortcut to commit changes directly to a pipe (or branch)

[Brian de Alwis]

I find that I frequently want to commit a set of changes to a different pipe than the current. Doing this currently is a five-step process:

  1. commit the changes locally
  2. switch to the other pipe
  3. merge -i from the original pipe
  4. pump
  5. switch back to the original pipe

It'd be lovely to combine this to something like:

  $ bzr commit --to-pipe pipe -m 'message' path/to/files

This is unfortunately far beyond my abilities.

Background/Justification (if it helps):

I'm using bzr-pipeline to create patches against a commercial product. I use a 4-stage pipeline to track development. The top-level pipe is against the pristine product trunk. The second-level pipe is used to track a few hacks that were necessary to make product to work in my environment. The third-level pipe is used to capture unit tests that I've created (this organization sees no value in unit tests). All my actual development is done in a fourth-level pipe. When I add/change a unit test, I need to commit those changes to the tests pipe.

[Aaron Bentley (abentley)]

I think you're leaving off a sixth step: committing in the other pipe.

I don't understand why you're committing locally. This is so that merge will work? Did you know that merge --uncommitted works with uncommitted changes stored in pipes? So I think you could do

bzr switch-pipe $OTHER
bzr merge -i $ORIGINAL --uncommitted
bzr commit
bzr pump
bzr switch-pipe $ORIGINAL

You could also use switch, instead of switch-pipe, to skip the merge step:
bzr switch $OTHER
bzr commit path/to/files
bzr pump
bzr switch/switch-pipe $ORIGINAL

I also don't understand why you're doing merge -i. Is that to select only the changes in the unit tests? Would merge pipe/path/to/files work?

Committing autogenerated changes straight to a branch isn't really the bzr way (e.g. merge does not commit), but pipeline is already violating that with the pump command, so it wouldn't be impossible to do here, either.

[Brian de Alwis (slyguy)]

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

[Aaron Bentley (abentley)]

We've had requests for this kind of functionality in bzr proper, so I think that would be the best place to implement this if we did.

[Vincent Ladeuil (vila)]

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

I think this can be avoided with 'bzr config bzr.transform.orphan_policy = move' (in any bzr config file you find appropriate).

@Brian: Can you confrm ?

[Brian de Alwis (slyguy)]

Hi Vincent. I use orphan_policy=move in a different project and it doesn't prevent the problem. The problem is not that the projects are renamed within the same directory but that the directories disappear and so Eclipse re-creates the directories where it expected to find them.