[RFC] Switch to move/copy concept instead of yank/cut/paste

[Brixy]

Is your feature request related to a problem? Please describe

Hi guys!

This may be a far-reaching idea. If it does not fit, please just close this issue ;-)

Currently you can yank or yank --cut single files or a selection of files. In the target directory you paste the files. This is probably how most TUI file managers work.

Will you be willing to contribute this feature?

Sorry – I am not a Rust expert.

Describe the solution you'd like

nnn uses a different concept: You just select one or more file, and in the target directory you either move (v) or copy (p) these files.

This seems more efficient, and I could think of these advantages:

• You need to decide only in the target directory what to do with selected files.
• It is arguably easier to copy or move selected files from multiple directories into a single target folder because there is no need to differentiate between yanking and cutting in advance.
• You just need to color code selected files because there is no need to differentiate between selected, yanked, and cut files.
• It’s actually easier to understand. Currently, if you select and then yank two files, then “re-select” one of those files, there is no visible indication. If you then hit d for example, it’s a bit hard to predict what yazi — and other file managers — will do. The proposed concept just knows two states: selected or unselected. Moving, deleting, and copying only refers to selected files.
• It would be sufficient to just support counting selected files. Again no need to support counting selected, cut, and yanked files, and no need to think about e.g. cutting and then re-selecting files.
• You can simply unselect files and move or copy the rest of the selection.
• No need to support “un-yanking” (see #313) or „un-cutting“ files.
• The current concept for deleting multiple files (first select, then delete) can be transferred to moving and copying.

Possible disadvantages:

• People are used to the current vim-like concept coming from other TUI file managers.
• The proposed concept would not support moving and copying files with one single paste command (which is currently not possible in yazi).

Currently if you want to cut and paste a single file you just need to press x and p.With the proposed concept it would be <Space> and p. There wouldn’t be much difference.

Describe alternatives you've considered

No response

Additional context

No response

[15cm]

Disclaimer: I didn't try nnn.

In the proposal, how do you tell whether your selection is finalized or not, under these scenarios:

• Yank multiple batches of files in the same directory with multiple select operations and then paste then to another directory with one hit.
• Yank multiple batches of files in the different directories with multiple select operations and then paste then to another directory with one hit.

[dan-da]

@15cm what does it mean for selection(s) to be finalized?

It seems to me that selections would always be "finalized" in the sense that at any moment the user could press a key to initiate move or copy of all selected files. After the key is pressed, the selections(s) would disappear along with the original file(s) for a move operation. For a copy operation, the selection(s) could remain, in case another operation is desired.

[15cm]

I didn't realize that multiple selections are supported. I thought I have to select a region, yank, and then select another region. My question got resolved and I'd vote for the proposal as well.

Some thoughts about the yank concept. In the GUI file managers we need ctrl-c or cmd-c to copy because the selection does not persists when you change the directory. However, the selection in Yazi persists until unselect and can serve as the clipboard by itself. I don't see the necessity of the yank clipboard either. The proposal is more like the DnD behavior in GUI FMs, where drop means copy and shift+drop means move.

[Brixy]

It seems to me that selections would always be "finalized" in the sense that at any moment the user could press a key to initiate move or copy of all selected files.

Yes, that’s it. You select as many files (and folders) across folders as you like, and when you are done you just perform a move or copy action in the destination folder. If, yet, the selected files should stay in place, you would just unselect everything using <Esc>.

Currently yanking/coping from multiple source folders is not supported, and it might be confusing.

This proposal would ‘just’ need to support cross folder selection.

[dan-da]

It seems to me that there could also be a symlink action, to keep original files in place, and link to them. Or really I suppose it should be softlink and hardlink, for the two possible types.

[sxyazi]

Sounds quite appealing, I'm still considering its potential pros and cons.

Since this is a proposal that could change user behavior, I'll be adding an RFC tag to see the community's opinion.

[Gajus84]

I like the idea. Maybe along with that a window that allows to quickly see the selected files in a list would then also come in handy.

[magnetophon]

People are used to the current vim-like concept coming from other TUI file managers.

This is a big one for me.
For years I have been using almost exclusively programs with vim bindings and it's a pleasure to rely on the same muscle memory throughout my desktop.

[patka-123]

I like this proposal a lot. Pasting the files in the location folder is much more intuitive. It doesn't deviate much from vim if you can just use p to put the file in the destination folder, right?

Or maybe it can be put behind a config value, so both options are possible? I'm not sure what the maintenance burden will be since I'm only a Yazi user that doens't know the code.

[LeXofLeviafan]

Sounds similar to how MC (Midnight Commander) does copying/moving. Though, its default mode is twin-panels…

[sxyazi]

Do we need support for cross-directory operations? If so, I'd like to know more about its details - how does it work?

Consider: I have selected /a/b/c, /a/b, /a. Now, if I cut them to /, what will the directory structure of / look like? Will it be just /a/b/c, or /a, /b, /c, or some other situation?

[Brixy]

Consider: I have selected /a/b/c, /a/b, /a. Now, if I cut them to /, what will the directory structure of / look like? Will it be just /a/b/c, or /a, /b, /c, or some other situation?

That's a good question.

nnn/cp for example will prompt

cp: will not create hard link './b/c' to directory './c'
cp: will not create hard link './a/b' to directory './b'

'Enter' to continue

and copy the directories to /a, /b and /c.

If you mark /a and /b/a nnn will just copy a single /a directory.

I hope I got your questions right.

[LeXofLeviafan]

Well, in the abstract sense, it'd make sense to simply copy/move all selected files/folders to the chosen destination (which would result in multiple copies of the same subtree when selected along with its parent for copying, and in the subtree being simply removed from the parent dir when selected for moving). Detecting subtree nesting would be a plus I suppose, though not exactly trivial considering possible existence of symlinks, hard links & bind-mounts.

The case of name collisions is more complicated, but it could be handled similarly to collisions with already existing files during regular copying/moving operations; i.e. when copying/moving a directory on top of existing one, they get merged (with optional confirmation), and in other cases the result would be either replacing the existing file altogether, skipping, or aborting the operation. The only important difference is that when the user tries to move multiple identically-named files, the replacing approach would result in losing all but one of them (…which is technically still viable, but the confirmation request would need to be IN ALL CAPS in this case).

…One way or another, it's probably a good idea to explicitly show the list which files/folders are going to be copied/moved to the user (possibly shortening long lists from the same source, e.g "…and 127 more from the same folder"), and/or all of the source folders (to avoid accidentally copying/moving unintended selection).

[magnetophon]

One way or another, it's probably a good idea to explicitly show the list which files/folders are going to be copied/moved to the user (possibly shortening long lists from the same source, e.g "…and 127 more from the same folder"), and/or all of the source folders (to avoid accidentally copying/moving unintended selection).

Fully agreed.
This would also be handy when deleting files, as requested in #285

[sxyazi]

@LeXofLeviafan Ah yeah, this reminds me that we also need to consider the repetition of /a/a/a when selecting /a, /a/a, /a/a/a, as well as how to merge if there's a b under /a and also under /a/a.

To handle these, we'll need to establish a basis in synchronous operations. However, Yazi's copy, cut, and delete are concurrent (which means that if we merge them, b could potentially come from /a/b or /a/a/b, and we can't determine the order of concurrency), and loading the directory tree happens simultaneously with these operations. Both sides are asynchronous, so it's not possible to foresee the complete list of files that might cause conflicts beforehand.

Maybe we can avoid users selecting potentially conflicting files in some way? For instance, displaying an error when /a is selected and /a/b is chosen, or delaying this notification until the user actually pastes. Alternatively, automatically de-selecting /a when /a/b / /a/b/c/d is selected, or /a/b / /a/b/c/d when /a is selected.

...There might be other better ways to handle this. I'm not sure what would be more intuitive; I haven't even used cross-directory file selection before :)

[LeXofLeviafan]

…Can't the operations be enqueued to run sequentially for each selection (potentially grouped by folder)? I.e. when paths A, B and C are selected, and a ‘copy’ to D is requested, there will be 3 operations added to a queue (‘A -> D’, ‘B -> D’, ‘C -> D’), and invoked in that order, polling the queue after completion of each operation. This might complicate the implementation a bit, but it would also make the outcome predictable (the app just needs to confirm how to handle collisions in the first place – which is needed for single path operations as well).

[sxyazi]

This requires introducing a queuing mechanism for the task system and allowing partial tasks to pause and wait for one or more tasks it depends on to complete before resuming.

If we prioritize based on the outermost directory, and execute a copy operation:

• /a/b/file depends on and needs to wait for /a/file;
• /a/b/c/file depends on and needs to wait for /a/b/file, /a/file;
• ...

And when any task on which a task depends fails, it won't be executed and should also be presented as a failure - this is somewhat counterintuitive; we might need to group interdependent tasks in a specific way, which can be very complex.

[Tweoss]

It seems to me that if copying or moving /a and /a/b, it would be okay to move just /a. I think this because /a/b is still copied or moved to roughly the right location (with an offset that user probably understands, given that they selected /a/b). Additionally, this approach likely would not require pausing / waiting (if I understand correctly), as we could merge the paths into their parents prior to executing any actual commands.

For example,/a/b/c + /a + /1/2/3 + /1/2/4 + /1/2 would be pre-processed into /a + /1/2.

I tried this out in Mac's Finder, where I had

- a
  - b
    - c
    - d

then selected /a/b and /a/b/d, and moved them to /. This just moved all of /a/b to /b.

While it does make more sense in a visual file manager like Finder (where you can expand folders without entering them), I think the result was still fairly intuitive.

[og900aero]

I've used several file managers: vifm, ranger, lf, joshuto, and I think the correct operation would be to copy and move only the given directory or/and file itself, not the entire complete path. So, if I select the following files and directories:

/a/b/file.txt
/c/file.log
/d/one_directory
/f/g/a/two_directory

then I want to copy these to the /home/user/Data directory, then the result should look like this:

home/user/Data/file.txt
home/user/Data/file.log
home/user/Data/one_directory
home/user/Data/two_directory

[sxyazi]

@Tweoss Basically agree. I'm just wondering if in this scenario there should be a way to indicate to the user that the outermost directory will be treated as the target.

Maybe when the user selects both /a and /a/b, we could use different colored blocks on the left side: /a in green 🟩 and /a/b in red 🟥.

Does this seem reasonable, or are there any other suggestions?

---

@og900aero If I select /a/file.txt and /b/file.txt, and do a paste them to /, what will happen?

---

Just reminded by @asim215 on Discord, I thought of a tricky question we've never considered - how to handle multi-tabs?

Currently, yank allows users to copy and paste between multiple tabs. With the new mode, does it mean that when a tab has files selected, other tabs will no longer be able to select files? Or does it mean that we will lose the feature of cross-tab file operations?

[Tweoss]

I think the colors make great sense!

In the comparison to Mac's Finder, though, Finder only has a single blue selection color. This does lower the mental work to understand selections. I think, perhaps, one reason to have a single selection state is for operations that don't conflict like copying and moving do. Bulk renaming would be one such operation.

Having colors, then, just distinguishes behavior for moving and copying. Other operations still use that selection.

I did some more experimenting and "New Folder with Selection" first moves selected child folders out to the same level as the selected parent folders, then creates the new folder with the selection. This could be another possible solution (move or copy inner items to topmost level, then proceed with updated selection; equivalently, apply move/copy operations to inner items before outer items).

Funnily enough, Finder produced a malformed archive when asked to archive a child folder / text file and its parent. I guess this shows how this is indeed a difficult problem we're trying to solve.

---

I'm wondering if we could think of tabs as registers. I think that it would be most natural to have each tab with their independent selections; otherwise, we might have a "spooky action at a distance" situation where some selections in different tabs are red or green for non-obvious reasons.

Additionally, pasting into, for example, tab 2 from selections in tab 1, 3, and 4 with a non-trivial merging heuristic would probably be very confusing.

For those reasons, perhaps we could treat each tab as a register, and enable pasting from different tabs with some bindable command. By default, p in a tab would paste from that tab's own selection. I'm not sure how we would have keybinds to paste from different tabs, as the numbers are already used to switch tabs. Ideally, 1p would paste from the first tab, but that is a conflict.

I can see how this register approach could add complexity to the mental model, so perhaps it is not the ideal approach.

[og900aero]

@Tweoss Basically agree. I'm just wondering if in this scenario there should be a way to indicate to the user that the outermost directory will be treated as the target.

Maybe when the user selects both /a and /a/b, we could use different colored blocks on the left side: /a in green 🟩 and /a/b in red 🟥.

Does this seem reasonable, or are there any other suggestions?

@og900aero If I select /a/file.txt and /b/file.txt, and do a paste them to /, what will happen?

Just reminded by @asim215 on Discord, I thought of a tricky question we've never considered - how to handle multi-tabs?

Currently, yank allows users to copy and paste between multiple tabs. With the new mode, does it mean that when a tab has files selected, other tabs will no longer be able to select files? Or does it mean that we will lose the feature of cross-tab file operations?

If you were to perform operations on the same location with files of the same name on different routes, then the current setup could remain, so

{ on = [ "p" ], exec = "paste", desc = "Paste the files" },
{ on = [ "P" ], exec = "paste --force", desc = "Paste the files (overwrite if the destination exists)" },

In other words, you copy to p by leaving the first one copied and renaming the next one, and to P the last file with the same name would overwrite the previous one.

I do not support the introduction of different colors for files in different places. I think the different colors should be associated with actions. For example:
Select - green (might better color is purple)
Copy - yellow
Cut - red

In the case of selections made on different tabs, two solutions are possible:

• Selections made on each tab (select, copy, cut) are independent of each other. This is more difficult to solve and I think it unnecessarily complicates the code
• All selections (select, copy, cut) on any tab are automatically synchronized with the other tabs. This is a simpler solution and does not complicate the code unnecessarily

Furthermore, I consider it important that if copying from different places to one place is realized, then there should be a function such that when the copy or cut operation is realized, the selections are automatically deleted after select, copy, cut. Otherwise, an action that we do not want may occur afterwards (deletion is an example). It would be good to link this action to a button, for example, because I have had many files selected for copying, but I changed my mind and wanted to delete the selection for copying, but I don't know, I can only delete the simple select action with ESC. The copy, cut mark is no longer there. I had to exit the program and then back in to get them deleted.

[og900aero]

As for multi-instance state synchronization, it is an independent and opt-in feature,

It is also a good solution to begin with, if the selection for copying can work from several independent libraries/files. But the best solution would be to select any file anywhere, synchronize it to another tab, another instance of yazi in real-time, and have a separate command for copy and cut, which is executed on the selected files and/or folders.

It conflicts with #319 (comment) and #319 (comment)

Actions:

select files in tab1 and press 'x' to cut them;
switch to tab2 to clear target directory by deleting files/directories using 'D' (permanent delete);
put files in the target directory by 'p' key.
With independent selections and actions for different tabs I able to remove selected files/dirs in (2) without affecting >(deleting) files in source directory (1). And then put them (3) in target directory.

It is not a good idea to issue different selections and actions on two different tabs of a file manager at the same time. This is specifically a very big mistake that can cause quite big problems. It is no coincidence that there is no known file manager that allows this.

[sxyazi]

@og900aero Hmm, to the best of my knowledge, any file manager that supports multiple tabs behaves in this way. Whether it's a TUI or a GUI, they all allow operations independent of tabs and enable copying or moving files between tabs. I use it like this every day, and otherwise, I'm not sure what the purpose of having multiple tabs would be.

[og900aero]

@og900aero Hmm, to the best of my knowledge, any file manager that supports multiple tabs behaves in this way. Whether it's a TUI or a GUI, they all allow operations independent of tabs and enable copying or moving files between tabs. I use it like this every day, and otherwise, I'm not sure what the purpose of having multiple tabs would be.

Yeah. That's normal for copy or cut between tabs (example yank files on tab 1 and paste in tab 2), but not normal for yank files on tab 1 and cut files on tab 2 and select files on tab 3, and paste operation whatever tab, because in such cases it is not possible to clearly decide what the good solution is. This case is not supported by any known file manager.

[Brixy]

Thank you for all the feedback.

I think it boils down to two concepts:

1) Select files/folders -> cd somewhere -> press p (paste) or v (move).

Color coding etc. is a bit easier, see #319 (comment).

2) Select files/folders -> x (cut) or y (yank) -> cd and to other stuff -> p to move or copy files.

The bolded part is probably very important for most people, as mentioned in #319 (comment).

In combination with #313 2) is probably what most people want, expect and are used to, even if coming from GUI file managers.

(If -- in addition -- x and y could be used simultaneously [and maybe even accross folders] it would be a phantastic addition. But it’s more complex than expected, see #319 (comment), #319 (comment) and other comments.)

EDIT: Cross posting. I did not read your latest comments before posting this 😉

[sxyazi]

@og900aero Hmm, to the best of my knowledge, any file manager that supports multiple tabs behaves in this way. Whether it's a TUI or a GUI, they all allow operations independent of tabs and enable copying or moving files between tabs. I use it like this every day, and otherwise, I'm not sure what the purpose of having multiple tabs would be.

Yeah. That's normal for copy or cut between tabs (example yank files on tab 1 and paste in tab 2), but not normal for yank files on tab 1 and cut files on tab 2 and select files on tab 3, and paste operation whatever tab, because in such cases it is not possible to clearly decide what the good solution is. This case is not supported by any known file manager.

I think you've confused some concepts. Please take some time (perhaps around 10 minutes) to carefully read the content of this RFC and the discussion below.

In short, Yazi is currently not exhibiting the behavior you described, nor is it heading in that direction. I don't want to provide further repetitive explanations here, sorry.

[sxyazi]

Thank you for all the feedback.

I think it boils down to two concepts:

1) Select files/folders -> cd somewhere -> press p (paste) or v (move).

Color coding etc. is a bit easier, see #319 (comment).

2) Select files/folders -> x (cut) or y (yank) -> cd and to other stuff -> p to move or copy files.

The bolded part is probably very important for most people, as mentioned in #319 (comment).

In combination with #313 2) is probably what most people want, expect and are used to, even if coming from GUI file managers.

(If -- in addition -- x and y could be used simultaneously [and maybe even accross folders] it would be a phantastic addition. But it’s more complex than expected, see #319 (comment), #319 (comment) and other comments.)

EDIT: Cross posting. I did not read your latest comments before posting this 😉

Perfect summary!

[evanescente-ondine]

What about a poll ?

[rharmonson]

Anyway, I like the vifm file manager solution the best for me. There is no separate button for selecting copy and cut, but there is only a simple selection, and the paste function is divided into the following:

little p -> paste with copy big P -> paste with move (cut)

There is no one right way to delete/copy/move files but I came here to see if vifm's method had been considered.

In vifm d+d deletes selected file(s) and moves to a trash directory which can then be p to paste (move) or u to undo. Ultimately, it results with one very comfortable (to me) delete or move operation.

Outside of the yazi's delete feature, I love what I am seeing. It a very nice file manager.

[jyothisv]

My two cents: conflicts arising out of multi-direct selection need to be addressed anyway as they happen now also when selecting files from fd's output.

Suppose we have files named a.txt in two or more sub-directories. Searching for a.txt using fd would list all of them. Now we can select, yank/cut, and then paste them into another directory. If this sequence is done using yazi, the output file would be just one a.txt (I don't know if there is any guarantee on which one). Similar operations in lf copies all files - one file would be named a.txt and the others would have suffixes like ~1~, ~2~ etc. This makes more sense to me.

[evanescente-ondine]

The renaming scheme should be customizable, just like graphical file managers ask how to rename individual files in case of conflict. But any scheme would do imho.

[sxyazi]

So, how about this proposal? Let's start with the simplest approach.

This RFC covers too many aspects (abolishing yank, cross-level selection, multiple tabs, state synchronization, conflict resolution, custom renaming schemes), and there are conflicts between them, making it challenging to implement this RFC.

[jyothisv]

So, how about this proposal? Let's start with the simplest approach.

This RFC covers too many aspects (abolishing yank, cross-level selection, multiple tabs, state synchronization, conflict resolution, custom renaming schemes), and there are conflicts between them, making it challenging to implement this RFC.

This covers one important use-case for me: within the same tab, I would be able to select files from multiple directories, go to the destination directory, and only then decide whether to move/paste.

[Brixy]

So, how about this proposal? Let's start with the simplest approach.

I would like to second this -- despite the original proposal of this thread.

[sxyazi]

Does anyone want to take on this task?

[rafo]

Reading the whole thread, but especially this:

So, how about this proposal? Let's start with the simplest approach.

This RFC covers too many aspects (abolishing yank, cross-level selection, multiple tabs, state synchronization, conflict resolution, custom renaming schemes), and there are conflicts between them, making it challenging to implement this RFC.

I wonder when yank (and copying?) is buried, can I no longer:

1. https://yazi-rs.github.io/docs/tips/#copy-selected-files-to-the-system-clipboard-while-yanking
2. And are the useful copy functions (that nnn doesn't have) still possible?

	# Copy
	{ on = [ "c", "c" ], exec = "copy path",             desc = "Copy the absolute path" },
	{ on = [ "c", "d" ], exec = "copy dirname",          desc = "Copy the path of the parent directory" },
	{ on = [ "c", "f" ], exec = "copy filename",         desc = "Copy the name of the file" },
	{ on = [ "c", "n" ], exec = "copy name_without_ext", desc = "Copy the name of the file without the extension" },

Sorry if I missed something...

[sxyazi]

@rafo No, this proposal #319 (comment) does NOT abolish any existing functionality, it only enhances the current functionality by allowing cross-level selection, whereas the current selection only supports selection within the current working directory. So it won't affect your use case.

[sxyazi]

Hi, I made a PR trying to implement this RFC, #693, let me know if it works for you!

[Brixy]

Wow! Thank you very, very much for your efforts.

For me, your PR works perfectly.

These things spontaneously come to my mind. (And please excuse, that I can only make some comments from a user’s perspective, but not contribute to your Rust code. I would love to …)

• When you yank or cut N files/folders and then select more files no additional selection counter (feat: add counter component to the header for displaying currently selected/yanked items #646) is visible. That’s absolutely OK but may be confusing when used across folders.
• When you yank N files, then select more files and press y again, should the current selection be added to the yanked files (as unyanking is supported now)? (Same maybe for cutting. But this would require an uncut command).

Thanks again. Yazi is just terrific!

(Tested with 60df56b.)

[og900aero]

Hi, I made a PR trying to implement this RFC, #693, let me know if it works for you!

For me working fine! Thank u this support!

[jyothisv]

Hi, I made a PR trying to implement this RFC, #693, let me know if it works for you!

Works great for me as well! Thank you very much for this feature!

Like @Brixy mentioned, I feel y/d should add the current selection to the yank/cut queue, instead of replacing it. That would also make yanking/cutting files from different tabs possible.

[sxyazi]

Thank you all for the test!

@Brixy

When you yank or cut N files/folders and then select more files no additional selection counter (#646) is visible. That’s absolutely OK but may be confusing when used across folders.

This is because the indicator on the left of the file list can only represent one state at a time, and the counter in the header also follows this approach to ensure consistency in behavior. There is some related discussion here: #682 (comment). Perhaps we can find a better way to optimize it in the future.

@Brixy @jyothisv

When you yank N files, then select more files and press y again, should the current selection be added to the yanked files (as unyanking is supported now)? (Same maybe for cutting. But this would require an uncut command).

I think this is a bit too complex. Besides implementing nested selection conflict detection, we also need to implement a "nested yank conflict detection".

I also haven't seen its use case - you can select all the necessary files in multiple directories by multiple times in batches and then yank them all at once, why do we need to yank them multiple times at each selection?

[jyothisv]

Thank you all for the test!

@Brixy

When you yank or cut N files/folders and then select more files no additional selection counter (#646) is visible. That’s absolutely OK but may be confusing when used across folders.

This is because the indicator on the left of the file list can only represent one state at a time, and the counter in the header also follows this approach to ensure consistency in behavior. There is some related discussion here: #682 (comment). Perhaps we can find a better way to optimize it in the future.

@Brixy @jyothisv

When you yank N files, then select more files and press y again, should the current selection be added to the yanked files (as unyanking is supported now)? (Same maybe for cutting. But this would require an uncut command).

I think this is a bit too complex. Besides implementing nested selection conflict detection, we also need to implement a "nested yank conflict detection".

I also haven't seen its use case - you can select all the necessary files in multiple directories by multiple times in batches and then yank them all at once, why do we need to yank them multiple times at each selection?

I was thinking of the case when we yank some files and then realize that we forgot to include some files. Yes we can do the paste and then come back for the new files. But if we want to say do the copying/moving in a batch (e.g., because the files are big and the file transfers would take a bit), the ability to add to the yank/cut queue would be handy. But not a big deal by any means.

[sxyazi]

@jyothisv

I see your point.

Yazi has a sophisticated scheduling system for copy and paste tasks, so you don't need to manually batch yank - paste these files. You can yank them all at once, let's say 10,000 files, and then paste them, and there won't be any issue. The scheduling system will add them to the queue and then execute them concurrently in order.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days. ⏳ This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.