Add --replace flag to move

[pokey]

Would be a substitute for --dest, and would accept a revset. Would be nice to support on #551 as well

With this discussion and #551, I'm thinking of a workflow where you can keep one branch which has your working copy with all the changes, and then duplicate the changes in one or more branches for review. These commands could enable a workflow for propagating changes back and forth between the branches by rewriting the sections as they change

[arxanas]

You might also want to check out git-branchstack by @krobelus.

Generally, in git-branchless, I don't separate the stacks out; instead, if I want to make changes to a previous commit, I just check it out and start editing it (and either run git amend to rebase the descendant commits, or git commit to defer rebasing until later).

It might also be desirable to have only one view locally and generate the individual branches for review synthetically as part of git submit.

You could probably also approximate this with something like git move -x def456 -d abc123^ && git move -s 'children(abc123)' && git hide abc123.

[pokey]

It would also be neat to have a configuration language like git-assembler, and even to make it two-way, and could auto update on merge. A lot of that could just be built on top of git-branchless tbh

[arxanas]

Although I'm not sure your proposal is quite right

Oops, I think you're right.

It would also be neat to have a configuration language like git-assembler, and even to make it two-way, and could auto update on merge. A lot of that could just be built on top of git-branchless tbh

It might be more straightforward to extend the existing revset language to be able to do side-effectful computations, i.e. just write something like

new_commits = move!(def456, abc123);
move!(children(abc123):, new_commits);
hide!(abc123)

It's perhaps worth noting that several git-branchless operations could be expressed in this way already. git sync is more or less equivalent to something like fetch!(main); move!(draft(), main) (except that it tries to move stacks individually, so that the failure of one doesn't cause the failure of others) and git restack would be something like (with made-up syntax) foreach(hidden():, x => move!((children(x) - hidden()):, successor(x)).

cc @martinvonz: for jj, we once talked about "what if instead of a main branch, we had a main revset?", for which we decided that wouldn't work for some cases, but what if we generalized it even further and had side-effectful revset scripts?

[pokey]

Yes I think a language like that would be awesome

I still think --replace is a useful flag as well, though

[pokey]

Re the revset language extension: would it be done speculatively and bail out entirely if there would be a conflict?

[arxanas]

I would envision it being done speculatively. There's probably more than one value on the spectrum of speculation. For example, for git sync, we essentially want to do "as much as possible and leave the rest", which is somewhere between "accept no conflicts" and "resolve all conflicts now". So ideally we could choose from any one of those three behaviors.