Non-stacky `pop`/`push`

[bonki]

Maybe this is somewhat the purpose of hide and I just don't understand how hide works or what its purpose is/how to use it (why does it leave the hidden patch's modifications in the work tree?) but would it be possible to have a non-stacky apply/unapply which doesn't affect the order of the patch(es) on/off the stack (to an extent where it's possible)?

I find myself re-ordering the stack using rebase -i way too often only for the sake of restoring an earlier, carefully crafted order (which can be really cumbersome).

When getting patches out of the way temporarily I would like to be able to de- and reactivate them at the "same" position (meaning on top of the patch which was parent at the time it was unapplied, if the commit still exists).

E.g. instead of

A
|
B
|
C
|
D
|
E
|
F <

$ stg pop B..C E
+ 0 A
+ 1 D
> 2 F
- 3 B
- 4 C
- 5 E

[...]

$ stg push B..E
+ 0 A
+ 1 D
+ 2 F
+ 3 B
+ 4 C
> 5 E

A
|
D
|
F
|
B
|
C
|
E <

I would like to be able to do

$ stg unapply B..C E
+ 0 A
- 1 B
- 2 C
+ 3 D
- 4 E
> 5 F

A
| \
|  B
|  |
|  C
| /
D
| \
|  E
| /
F <

$ stg apply B..C E
+ 0 A
+ 1 B
+ 2 C
+ 3 D
+ 4 E
> 5 F

A
|
B
|
C
|
D
|
E
|
F <

Is this a silly request?

[jpgrayson]

This request is framed in terms of StGit maintaining memory of historical patch ordering(s).

In this discussion, @lthms writes about an idea for StGit to have the concept of patch dependencies.

I wonder if patch dependencies would be a viable alternative mechanism to meet this workflow desire?

I guess I'm viewing it as patch dependencies would allow one to encode the relative ordering of subsets of patches versus this idea which establishes a single global ordering.

With this idea, one immediate question is: what happens to the remembered global ordering when operations like new, float, or sink happen on patches in the active stack? Would those just invalidate the remembered global ordering? Or are there obvious transformations to the remembered global ordering that should happen in response to reordering operations on the active stack?

[lthms]

For the three examples you mentioned, I would suggest

• By default, new creates a patch with no dependencies; we can imagine having a new command-line argument to specified said dependencies though
• float and sink are by default constraint by the ordering (i.e., they cannot go past a dependencies or rev dependency); we can imagine --force that would effectively remove dependencies that would block patch movement otherwise.