Comments 55
т.е. вы сделали:
git pull
rename_some_files
git add .
git commit -m "renamed files"
git push
про это статья?
В частности, и про это тоже.
Я недавно начал использовать Git и GitHub. Цель написания этой статьи — возможное получение полезных советов от опытных пользователей. Я думал, возможно, кто-нибудь посоветует альтернативные способы переименования множества файлов, более оптимальные, чем я описал.
Эм, вы то есть вы недавно познакомились с технологией и решили об этом написать на техническом ресурсе (или уже не торт)? Ресурсе, который, в сути своей, подразумевает несколько более высокий уровень вовлечения в технологию.
Знаете, я недоволен.?
Я могу вас понять. С другой стороны, как автор может определить необходимый уровень статьи, который подходит для Хабра? Я не видел в справке Хабра никаких конкретных условий по этому поводу. Я готов соблюдать такие условия, если их пропишут.
Когда-то Ричард Фейнман взорвал бутылку в институтской лаборатории. Взорвал в результате эксперимента. И ещё ректор изрёк, что опыты новичков должны проводится в лаборатории для новичков... Фейнман стал нобелевским лауреатом.
О чем я? Выводы сами делайте.
Если не хотите читать такие статьи, то может плашку-хештег придумать "для новичков".
P.S. не судите человека строго.
Ну вот, плашку уже придумали, она отображается перед тем как зайти. Мы ее здесь обсудили https://habr.com/ru/articles/745312/#comment_25708846
О чем я?
Ни о чем
Эта претензия скорее к администрации Хабра их политике - "Даешь любой контент, главное больше конверсии" (возможно за исключением совсем лютого трэша и запрещенки, возможно рекламы в обход партнерок).
Цель написания этой статьи — возможное получение полезных советов от опытных пользователей.
Обратите внимание на существование рядом ресурса для получения советов и прочих ответов на вопросы: qna.habr.com
Хорошее замечание, спасибо. Как-то забыл про этот сервис (в отличие от Stack Overflow, на котором я задал вопрос, но отклика пока не получил). Но я не уверен, что на указанном сервисе можно задавать вопросы с большим текстом (сравнимым по размерам со статьей), содержащим разное сложное форматирование. Я заходил туда, там обычно вопросы на несколько абзацев и почти без форматирования. Этого недостаточно.
Вы правы, я многого не понимаю. Если вам несложно, может быть, вы дали бы мне какие-нибудь более конкретные замечания? Я был вам за это благодарен.
вы вообще не понимаете, что такое github и зачем он нужен
Я использую этот веб-сервис для хранения файлов с кодом. Это удобно. От администрации веб-сервиса я никаких страйков за это не получал, значит, мне кажется, всё в порядке.
поймите, что писать пространные статьи о настолько рутинных операциях, которые буквально каждый разработчик делает несколько раз в день, на Хабре – это плохая идея. Вас просто не поймут.
Вы молодец, у вас много знаний. Но я рассчитывал на людей, которые только начинают изучать Git, GitHub и так далее. Такие есть, их много. Для них эта статья будет интересной и полезной.
Дело в том, что опытные разработчики не будут писать такие статьи, как вы и сказали сами, потому что для них это слишком просто. Откуда тогда начинающим разработчикам узнавать основы? Кто пишет для них? Мне кажется, Хабр предназначен не только для опытных разработчиков, но и для начинающих.
Средний
ну тогда как минимум уровень статьи имело бы смысл понизить.
При выборе уровня «Средний» я ориентировался на справку Хабра. Там сказано, что «Средний» уровень подразумевает знание читателем основ, которые автор не будет разъяснять. В данной статье я не объясняю, что такое «Git», для чего нужен «GitHub», как работать из командной строки и что это такое, что такое программа-оболочка, что такое программа-«эмулятор терминала», что такое регулярные выражения, что такое скрипт и так далее. То есть в этой статье огромное количество терминов, которые читатель должен знать и понимать, я это всё не разъясняю. Поэтому уровень статьи «Средний», хотя я бы с удовольствием выбрал «Простой», но данная статья объективно ему не соответствует.
то, что вы написали в статье это тоже основы основ
Мне кажется, нужна более сложная классификация. Вместо простой-средний-сложный, нужно что-то вроде
для вообще начинающих (домохозяйка)
для начинающих, но знакомых с основами (джуниор)
для среднего уровня (сеньор)
для сложных тем (тимлид)
И описание этих категорий, наверное, стоит сделать более подробным.
Автор, то, что вы сделали - это подходит только для случая write-once файлов. То есть вам не нужен git blame для них.
git mv, с рядом оговорок, сохраняет историю изменений; ваше не делает так (тоже с оговорками, впрочем).
Как бы сделал я:
find . -name "*" -exec sh -c 'x={}; git mv "$x" $(echo $x | sed 's/-/-0/g')' \;
На всякий случай, можно дополнительно указать для find -type f
Я работаю в «Windows 10», не в «Linux», но спасибо за ваш код. Насколько я понял, вы предлагаете таки использовать команду git mv, но до ее запуска в строке конструировать параметры для нее в нужном виде. Таким образом, всё же можно будет использовать регулярные выражения, несмотря на то, что git mv сама по себе их не поддерживает.
Думаю, это можно реализовать и в PowerShell.
вы может быть удивитесь, но попробуйте выполнить вышеуказанную команду в виндовс, где стоит гит, и обнаружите что вместе с гитом у вас теперь на виндовс есть и find и sed и даже git-bash
UnixUtils
uutils
...
git/bash
Это всё прекрасно работает в Windows, и там всё это можно делать. В PS тоже можно, конечно.
Даже если не брать в расчёт "десятку" (о чём уже написали в комментариях до меня), то начиная с самых древних винд (а может и в досах это уже было? UPD: появилось в досе со второй версии) есть конструкция FOR. Дальше только дело техники вычленить нужные части имени файла и соорудить новое имя.
Git достаточно умный, что бы автоматически определить переименовывание по содержимому. Даже если оно было немного изменено.
Однако это дорого, поэтому есть лимиты на количество сравниваемых файлов в угоду производительности, которые по умолчанию довольно низкие.
А еще есть утилита rename, которая на вход умеет wildcard-ы принимать.
Кстати, На DistroTube-канале у Derek Taylor есть видос, где довольно много способов переименования описано.
Ну не знаю.. Оно попытается что-то сделать с файлами внутри .git, у него не получится, но осадочек останется. Еще меня смущает, если мы переименовали файл - не найдет ли его find повторно?
Да, это спорный скрипт; но я его сделал за 5 минут, он выполнил задачу (я специально сделал тестовый репозиторий, создал в нём файлы по маске, и поделал в них изменения), и вроде бы последствий на тестовой репе не было.
Поэтому я его привёл как рабочий пример (идею), который можно дальше тюнить в любую сторону.
Я написал что-то похожее на PowerShell:
Get-ChildItem -File -Recurse |
ForEach-Object {
$old = $_.Name
$new = $old -replace '^(\d\d)-(\d\d)_(.*)', '$1-0$2_$3'
if ($old -ne $new) {
$path = $_.DirectoryName
Invoke-Expression "git mv $path\$old $path\$new"
}
}Спасибо еще раз за подсказку, плюсанул в карму.
Опять какой-то препод требует статей на хабре для зачёта? Что это тут делает? "Я переименовал файлы и запушил". Предлагаю темы следующих статей: "я зашёл по ssh на сервер и посмотрел список процессов", "я запустил докер-контейнер, а потом остановил", "я включил компьютер, на мониторе появилось изображение".
Коллеги, по-моему, вы уж слишком напали на автора.
Все когда-то начинали.
Написать скрипт для переименования множества файлов проекта и переименовать их;
Скрипт, конечно, получился несложный и пишется быстро, если хорошо знаешь PowerShell, но я бы обошелся функционалом "Групповое переименование" в Total Commander.
В остальном статья совсем не про переименование файлов, а про то, как клонировать репу, делать коммит и пуш. Эти примитивные операции описаны в учебнике по гиту на https://git-scm.com/book/ru/v2
HetmanSoftware перелогиньтесь
Powershell не умею, но получилось ужасно. Среди 100500 способов переименовать файлы автор выбрал, пожалуй, самый странный. Интересно, как так получилось, что у него в репозитории все файлы .cpp оказались вот с такими вот именами? И какую задачу призвано решить переименование?
Среди 100500 способов переименовать файлы автор выбрал, пожалуй, самый странный.
Мне нравится язык PowerShell, поэтому я пишу скрипты на нем. Но эта статья написана в том числе и для того, чтобы узнать возможные альтернативы. Кое-что мне посоветовали в комментариях. Я благодарен тем, кто посоветовал.
Интересно, как так получилось, что у него в репозитории все файлы .cpp оказались вот с такими вот именами?
Я читаю учебник по языку C++ и создаю файлы с кодом для всех примеров и упражнений из этого учебника. Файлы нумерую по принципу 00-00, где первые две цифры — для номера главы учебника, следующие две цифры (после дефиса) — номер примера/упражнения в рамках главы.
И какую задачу призвано решить переименование?
Количество примеров/упражнений в рамках главы превысило 99 штук, цифр стало не хватать, этого я изначально не предвидел. Поэтому решил увеличить место для номера с двух до трех цифр. Теперь доступна нумерация до 999 штук.
Я читаю учебник по языку C++ и создаю файлы с кодом для всех примеров и упражнений из этого учебника
Подход понятен. В этом учебнике нет рекомендаций по поводу того, что все сущности в программах нужно называть осмысленно? И переменные, и функции, и классы, и сами файлы? Не должно быть названий вроде "MyStruct", "SomeClass", "CoolProject" и "00.cpp", "001.cpp" и т.д. Даже в учебных и тестовых проектах нужно приучать себя давать везде и всему осмысленные названия.
У меня осмысленные названия, их можно увидеть в статье. Например:
00-000_helloworld.cpp
00-001_helloworld-wait.cpp
00-002_cpp17compat.cpp
...и так далееЗа осмысленность отвечает часть названия, которая идет после нумерации. Там, где автор учебника даёт названия файлам, я оставляю авторские названия, только добавляю свою нумерацию в начало названия файла (автор учебника не всем файлам дает достаточно информативные названия, потому что это лишь учебные примеры; сам учебник достаточно хорош, там о наименовании файлов, переменных и т.п. довольно емко написано).
После 00-99 спокойно следует 00-100 ;) Можно спокойно оставить как было, ничего для программного кода не изменится.
ЗЫ: у меня достаточно часто возникает похожая задача с переименованием чужих картинок. Чтобы порядок в слайдшоу не ломался. Это 1 строчка на bash, но никак не статья в хабр.
ЗЫЫ: складывать 100500 файлов с программным кодом, никак друг с другом не связанных, в одну папку - это ужасно. Идея о вложенных папках должна возникнуть не позже чем на 11 задании ;)
После 00-99 спокойно следует 00-100
Конечно, можно было и так, но это неудобно из-за сортировки. Некоторые системы, в которых я просматриваю списки файлов, отображают файлы так, что файл 00-100 идет в списке вместе с файлами 00-10, 00-11, 00-12 и т.д., а не после 00-99, как мне нужно. Насколько я помню, в веб-интерфейсе «Гитхаба» файлы сортируются именно так.
Это 1 строчка на bash, но никак не статья в хабр.
Тут не просто переименование файлов или переименование файлов в Git-репозитории, а переименование файлов на веб-сервисе «Гитхаб». Я думал, что мне посоветуют какой-нибудь способ автоматизации на самом этом веб-сервисе. Там, вроде, есть средства автоматизации, но я с ними незнаком. Пока ничего такого не посоветовали, к сожалению.
складывать 100500 файлов с программным кодом, никак друг с другом не связанных, в одну папку - это ужасно
В данном случае это не совсем программный проект, поэтому подход другой. Пользоваться этими файлами удобно, если плясать от чтения учебника. Я делаю этот проект для людей, которые будут учиться по данному учебнику, для них группировка по главам удобна. У меня уже был подобный опыт с учебником Роберта Лафоре пару лет назад. Получилось неплохо.
Я делаю этот проект для людей, которые будут учиться по данному учебнику
ИМХО, весьма ограниченная аудитория у статьи получается. Я ни разу не видел ни в одном проекте такого.
Совет для PowerShell, предваряйте скрипты установкой данной переменной. Она завершает выполнение скрипта на первой же ошибке.
$ErrorActionPreference = "Stop"Мне удобнее видеть кучу ошибок, как это происходит по умолчанию. Но всё равно, спасибо за совет. Я пользовался переменной $DebugPreference, а про упомянутую вами был не в курсе. Сейчас почитал про нее в документации.
GitHub: переименование множества файлов в репозитории