Add "copy" command

[pokey]

It would be good to have a version of move that doesn't remove the original commit(s). Basically like a cherry-pick, but with all the benefits of git-branchless move, eg revsets, in-memory operation, --insert, etc

[arxanas]

I've sometimes wanted to do this. I wonder if it would be better to add a --copy flag to git move, rather than create an entirely new command?

As far as the implementation, it seems like it should be as simple as inhibiting the part where we call the post-rewrite hook with the rewritten commits, but maybe there's some complication where we implicitly rely on committing something and then immediately rewriting it in order to execute the move.

[jomakaz]

I think it would be weird to have git move --copy ... compared to git copy .... Copy command is more cleaner.

[arxanas]

After mulling it over for a while, I think a git copy command would also be cleaner. But in the long run, I don't plan to implement a git-branchless copy command myself (although I would accept a PR implementing it). Instead, I would defer to Jujutsu for that, as per #654. It already has a jj duplicate command, although it doesn't yet have all the cool features like --insert.

[pokey]

I often find myself wanting this feature. Is there a decent workaround, or any hope of it being implemented at some point? I would think it would be an easy addition, but I don't really know the code base well enough to know for sure

[arxanas]

@pokey In those cases, I just use git cherry-pick and don't use an in-memory method of duplicating the commit.

[pokey]

Yeah that's what I do as well. I guess I'm just spoiled by the slick in-memory branchless move 😄

[zachallaun]

Just want to throw my hat in the ring in favor of this. I came to suggest it and found this thread instead :)

I personally think that integration with move is the way to go, as --copy would be usable and useful with all of the existing flags for move: -b, -x, -I.

[pokey]

Regarding implantation, @arxanas said:

As far as the implementation, it seems like it should be as simple as inhibiting the part where we call the post-rewrite hook with the rewritten commits, but maybe there's some complication where we implicitly rely on committing something and then immediately rewriting it in order to execute the move.

Which sounds like what you said I think

And I agree I would love to have this feature. I'm so used to the slick move command that I balk a bit every time I have to muddy my hands with a cherry-pick. Feels beneath me now 😤😊

[zachallaun]

Doh! Not sure how I missed that; thank you!

[pokey]

No worries 😊. Fwiw @arxanas mentioned elsewhere in this discussion that a PR would be welcome

[claytonrcarter]

it seems like copy would be a matter of not marking copied commits as rewritten?

@zachallaun in the simplest of cases, yes, this seems to be the case. I played around w/ this just now and – after propagating the --copy flag into the appropriate functions – getting a simple case was easy by just skipping the "post rewrite" clean up altogether. (You can see the changes needed at https://github.com/claytonrcarter/git-branchless/tree/move-copy; the first commit is the boring struct plumbing, the last commit is the interesting part.) This worked for the one test case I tried, and may be sufficient if copying subtrees is all you need.

If we need to copy in conjunction with --insert, --exact, etc, (and I think that these are where all of the fun is!) then it's more complicated because we will need to selectively rewrite/hide commits depending on the flags passed to git move. That is to say, flags that affect the source stack (eg --exact causes commits to be "removed" from the source stack) would need to skip the "mark obsolete/rewritten" step, but flags that affect the destination stack (eg --insert needs to legitimately move/rearrange some commits in the dest stack so that new commits appear to be inserted) would probably need to still be processed for obsolete/rewritten.

All that being said, I'm probably overlooking something, or misunderstanding the use case and making it more complicated than it needs to be! 😄

I'd be interested in trying to contribute this.

I think that this would need updates to the rebase planner (to record which commits in the plan are in the source vs destination stacks) and also in the rebase executer (to only rewrite the destination stack, but not the source stack). So it may be an adventure!

I don't intend to work on this any more (I don't really use cherry-pick), but I've worked w/ the rebase planner and executor a bit, and may be able to offer feedback or guidance if you do decide to work on this.

[zachallaun]

Thank you very much for your work on this! This is extremely helpful and a great boost to get started. I agree that copy along with the extra flags is indeed the fun/useful bit.

I may not be able to work on this immediately, but I'll circle back around to this later this week or weekend. From my own exploration of the code, I agree that the rebase planner may need some modification, but hopefully not too large. Thank you for the offer of feedback/guidance if it's needed!