QtCreator, для левой панели в режиме FileSystem есть ли перетаскивание файлов?

Наверное из-за таких вот упорантов там добавили дерево, вообще пользоваться невозможно теперь.

А в чем невозможность? Я просто не использую дерево фс.

Если работаешь с git и совершаешь например переименовывание/перемещение файла НЕ через команду git mv, то затем git будет отображать удаление одного файла и создание второго, что плохо, т.к. не видно по истории изменений, что вот этот файл1 раньше был файлом по имени файл0. Поэтому перемещения/переименовывания лучше делать через команду git mv.

Наверное из-за таких вот упорантов там добавили дерево, вообще пользоваться невозможно теперь.

Дерево в режиме Projects мне и самому не нравится. А вот в режиме File System очень даже. Когда проект насчитывает сотни файлов, то очень тяжко по ним лазать если они одним однородным списком.

А в чем невозможность?

Перегруппировывать файлы проекта, разбивая их по группам (файловым папкам) или перетаскивать в другие группы.

Что бы перетащить в другую группу, нужно закрыть IDE, перетащить через файловый менеджер, а после в IDE переправить файл .pro и #include если это хедер.

Для сравнение, функция переименования хедера там полностью автоматизирована. Переименовал, а все остальные ссылки на него сами изменились.

Решение что нужно один список файлов как-то разбить на более маленькие группы принимается не сразу, а когда файлов в одном месте накпливается больше какого-то N штук, тогда и начинаются заморочки.

См. мой ответ про git mv.

лучше делать через каманду git mv
См. мой ответ про git mv.

Редко пользуюсь историей, хотя и поставил ее обязательное создание при каждой успешной компиляции, иногда спасает. Выполняет ли IDE ее при переименовании не обращал внимания, но если нет, то так же можно было бы на форуме вопрошать, ну почему разрабы этой тулсы не подумали об этом.

См. мой ответ про git mv.

Реально по группам очень удобно ориентироваться, но очень не хватает управления этими группами.

Я просто не использую дерево фс.

А я использую, для перехода к соседним файлам. Точнее раньше использовал, так как сейчас часто приходится прибегать к горизонатльной прокрутке, чтобы имя файла увидеть целиком

Дерево в режиме Projects мне и самому не нравится

А без дерева в этом режиме толку вообще ноль, тысячи файлов в плоском списке это бред

Если работаешь с git и совершаешь например переименовывание/перемещение файла НЕ через команду git mv, то затем git будет отображать удаление одного файла и создание второго

Нет. Он в состоянии определить переименование, если содержимое не сильно поменялось.

Поэтому перемещения/переименовывания лучше делать через команду git mv.

Создал репозиторий, добавил туда файл с текстом, сделал git mv, заменил текст в файле, добавил в индекс и переименование распалось на удаление и добавление.

Так что всё равно. git mv это просто небольшое удобство, чтобы переименование и обновление индекса делать одной командой. Сам git переименование никак не записывает (просто негде, коммит – лишь текст, ссылка на дерево и немного мета-информации о самом коммите) и использует эвристики для определения его наличия.

Не определяет он сам. Во всяком случае всегда.

А без дерева в этом режиме толку вообще ноль, тысячи файлов в плоском списке это бред

Мне в режиме Projects не нравится т.к. он разделяет при этом на Headers & Sources. Поэтому пользуюсь File system, там такого неудобства нет. Но перетаскивания файлов между папками нет и в Projects.

Не определяет он сам.

https://asciinema.org/a/zaeDsIqdNbwjkd9jGghbnH5Ok

Во всяком случае всегда.

Я и не говорю, что он всегда определяет. Но git mv никак не помогает ему в определении переименования. Если думаешь иначе, то покажи пример, где git mv и git rm --cached + git add дадут разный результат.

Просто так переместить ты и в файловом менеджере можешь. А тут надо и поддержку в менеджере проектов придется пилить, и в VCS - а никто этого не сделал. А потом придется добавлять вторую панель вместо редактора, потому что без двух панелей таскать файлы все равно неудобно.

В файловом менеджере переместить могу, но это куча действий: закрыть куте, переделать, открыть, переправить все ссылки и главное ничего не забыть.

В менеджере проектов поддержка переименования есть. Т.е. это урезанный функционал от файлового представления. А в файлом представлении есть даже создание папок и переменование папок, только чуть не допиленный.

Т.е. операция перетаскивания это по большому счету просто припилить к этим операциям возможность drag&drop.

Вторую панель не нужно (хотя она и есть справа)), все и так будет удобно, сто лет в проводниках видовых и линуксовых живем с одной панелью, уже давно отучились от роскоши дос-навигатора.

ИДЕ от МС прекрасно справляется с перемещением без второй панели, например.

В менеджере проектов поддержка переименования есть

Переименования, а не перемещения. Чтобы файл переместился, надо найти .pro-файл, в который файл надо переместить, удалить из старого и добавить в новый. При этом однозначного соотвествия между каталогами и .pro-файлами нет, возможно придется еще показывать пользователю диалог с выбором, чтобы уточнить намерения.

В файловом менеджере переместить могу, но это куча действий: закрыть куте

Зачем??

переправить все ссылки

Все равно придется, сейчас даже функция переименования правит только .pro, а исходники правишь сам.

найти .pro-файл, в который файл надо переместить

Хотя бы в пределах одного pro. Многие же как делают новый блок изменений, понаделают быстро кучку всего, убедяться что работает, а потом наводить порядок. А сразу наводить порядок на каждую строку, на вещь, которая не известно еще получиться ли, это избыточно.

сейчас даже функция переименования правит только .pro

При переименовке хедера все правит, и исходники. У меня так. Поэтому перемещение в пределах одного .pro это не сильно усложнит уже имеющиеся механизмы.

закрыть куте, Зачем??

Да, закрывать действительно не нужно, структуру сразу обновляет. Но тем не менее, все равно куча действий, иногда забываю что-то доправить, компилируется долго, при переименовки спп нужно объектники чистить.

Так что всё равно. git mv это просто небольшое удобство, чтобы переименование и обновление индекса делать одной командой. Сам git переименование никак не записывает (просто негде, коммит – лишь текст, ссылка на дерево и немного мета-информации о самом коммите) и использует эвристики для определения его наличия.

Нет. Имеем коммит 0000. Переименовываем файл file0 в file5. Делаем коммит (пусть будет 0001). Смотрим разницу между коммитами 0000 и 0001:

# git diff 0000 0001
# вывод:
diff --git a/file0 b/file5
similarity index 100%
rename from file0
rename to file5

использует эвристики для определения его наличия.

similarity index 100%

Ни на что не намекает?

Может хоть это убедит:

$ git show
commit 7d29214ef91c99d71b4e97d79ca1890abffef240
Author: xaizek <xaizek@posteo.net>
Date:   Wed Jul 24 13:06:03 2019 +0300

    another commit
---
 a => b | 0
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/a b/b
similarity index 100%
rename from a
rename to b

$ git config diff.renames false

$ git show
commit 7d29214ef91c99d71b4e97d79ca1890abffef240
Author: xaizek <xaizek@posteo.net>
Date:   Wed Jul 24 13:06:03 2019 +0300

    another commit
---
 a | 1 -
 b | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/a b/a
deleted file mode 100644
index 8bd6648..0000000
--- a/a
+++ /dev/null
@@ -1 +0,0 @@
-asdf
diff --git a/b b/b
new file mode 100644
index 0000000..8bd6648
--- /dev/null
+++ b/b
@@ -0,0 +1 @@
+asdf

man git-config:

diff.renames

    Whether and how Git detects renames. If set to "false", rename detection is
    disabled. If set to "true", basic rename detection is enabled. If set to
    "copies" or "copy", Git will detect copies, as well.

    Defaults to true. Note that this affects only git diff Porcelain like
    git-diff(1) and git-log(1), and not lower level commands such as
    git-diff-files(1).