FR: jj duplicate -d

[dpc]

Is your feature request related to a problem? Please describe.

I wanted to backport a revset to a branch. I'm a noob, I'm aware of jj rebase -s x -d f and seemed like the perfect way to do it, if only it could ... duplicated the x. There is jj duplicate but it can't -d.

Describe the solution you'd like
jj duplicate -s x -d f

Describe alternatives you've considered
I did jj duplicate x, then jj rebase -s y -d f, but that clumsy because now I need to figure out y from the output of first command, and it was unclear does it print it top down, or bottom up.

[yuja]

Another option is to add rebase --keep (which was suggested by @martinvonz.) I'm not sure which one is more discoverable, but extending rebase might be easier.

[martinvonz]

I'm not sure which one is more discoverable, but extending rebase might be easier.

It also means we won't have to reimplement --insert-before/-after (#3396) for duplicate.

[dpc]

If you have rebase --keep is there any reason to have duplicate anymore?

Personally I think duplicate is more intuitive and discoverable, and handier than an extra flag to rebase, but no strong feelings about it. Under the hood, it could be the same code with a flag all the same.

BTW. When using duplicate I was confused about what is going to happen. Is it going to be a sibling? I guess it has to be, but maybe I'm wrong. Of only one change? More? jj duplicate -h doesn't answer these questions. If duplicate supported the same sets of flags as rebase and -d defaulted to @- and -r to @, and there also was -s then it would have been immediately clear.

[necauqua]

If adding a useful flag to rebase also happens to make it a complete superset of duplicate, then it's another merge -> new/commit -> desc+new situation.

For which my answer was always is that there should be one command doing one thing and convenient/discoverable alternatives should be default aliases or something.

jj duplicate -h doesn't answer..

fyi in clap --help shows more info than -h, which I've discovered no idea how as I'm always using -h, ugh
While this does not help at all with duplicate, there's a ton of useful text in jj rebase --help I've read several times 🙃.

[arxanas]

My own conclusion is that if the command is logically different to the user, then it should be exposed via a different command, even if it accepts all the same arguments and/or is backed by the same implementation.

My test is: if you were looking through the subcommand list to try to copy commits, would you have seen rebase and decided to look at its arguments further? I don't think I would have. (I don't find duplicate to be a particularly obvious term, but if I were looking through the list, I would at least note it mentally.)

The logic would also apply to jj run/git-branchless test.

• Fixing a bunch of commits is kind of like running a command on each of them, but not obviously the same (it really depends on what you think it means to "run" a command on a commit), so I think they ought to get separate subcommands, even if the implementations are highly intertwined.
• Likewise for searching (bisecting) and minimizing commits.
  • But something like probabilistic search probably belongs in the same search subcommand as regular deterministic binary search, even though the implementations are probably very different.

I could see an argument for also adding a helper flag like jj rebase --copy, but I haven't thought it through much.

[yuja]

My test is: if you were looking through the subcommand list to try to copy commits, would you have seen rebase and decided to look at its arguments further? I don't think I would have. (I don't find duplicate to be a particularly obvious term, but if I were looking through the list, I would at least note it mentally.)

I agree. My use case is cherry-picking (or graft-ing in hg sense), and I wouldn't see it as a rebase operation.

FWIW, the current jj duplicate doesn't behave like jj rebase -d if multiple non-contiguous revisions are selected. So if we add jj duplicate -d, I would also want to change the default behavior for consistency.

[arxanas]

Wanted to reproduce @yuja's Discord comment:

fwiw, I prefer jj duplicate/graft/cherry-pick than jj rebase --keep because the use case may be different. the behavior is also a bit different in that new change ids will be assigned to the rebased commits.

I concurred and mentioned how it might be useful:

The semantic difference re change IDs seems useful in practice, actually; in fact, there are cases where I'm rebasing and intending to resolve the divergent change IDs later, and there are cases when I'm genuinely duplicating the commits
For example, rebase and run checks and hide old stack if the new stack works (obviously you can undo as well, but it's not my preferred workflow, I would really like to consider both stacks at once)