А ещё лучше код прикладывать не скринами, а кодом:
@OptIn(Experimentatcontracts::class)
fun isHybridCarWithMainElectroAndDieselAdditional(car: Car, mainMotor: Motor, additionalmotor: Motor?): Boolean {
contract {
returns(true) implies(car is Hybrid)
returns(true) implies(mainMotor is ElectroMotor)
returns(true) implies(additionalMotor is DieselMotor)
}
return car is Hybrid && car.mainMotor is ElectroMotor && car.additionalMotor is DieselMotor
}
fun checkCar(car: Car) {
when {
isHybridCarWithMainElectroAndDieselAdditional(car, car.mainMotor, car.additionalMotor) -> {
println("Doing with hybrid and main electro motor and diesel additional motor")
car.mainMotor.iAmElectro()
}
}
}
Обычно при работе в команде влитие идёт через Merge/Pull Request, а он завязан на ветку - новая ветка это новый PR, а значит всё обсуждение из старого "теряется", оставая в старом - это как минимум не удобно. Да и разницы между force-пушем в свою существующую ветку и созданием новой ветки с удалением старой практически нет. Кроме того что ветка будет новая что отразится на том что завязано на имя ветки.
А зачем вообще избегать force-пуша? Это же сервер просто предупреждает о том, что он не сможет плавно переместить указатель ветки на новый коммит - то есть переместить так чтобы не потерять ни один из коммитов входящих в ветку в данный момент, а если локально проводился squash, amend или rebase, то это как раз и приводит к ситуации когда часть коммитов (про которые знает сервер) из ветки выпадают и force при пуше просто говорит ему "да, клиент знает что делает - терять коммиты можно".
При командной работе force-пуш в релизные ветки обычно запрещён политиками, изменять что-то в чужих в целом не принято, а с историей коммитов в своих ветках можно делать всё что угодно.
Нужно найти определённую строку в нескольких столбцах: ИИ пишет ручную проверку каждого из столбцов, хотя поддерживаемей и расширяемей - сохранить индексы столбцов, надённых по регулярке и бегать по ним в цикле - при расширении списка столбцов достаточно поменять сконфигурированную регулярку вместо того чтобы добавлять в ИИ-код проверку ещё N столбцов.
Вот как раз вчера была задача "распарсить CSV", сгруппировать данные по одному столбцу и превратить 4 других в правильно сформированную ссылку. Я вообще Java-разработчик, но тут вроде как хорошо подходит Python - взял платный (вроде) Claude и попросил реализовать скрипт максимально расписав задачу - потом всё равно процентов 40 переписал ибо на сколько подробно ни описывай задачу, но всё равно сделает не так как я "вижу", а где-то проще, где-то не эффективно, где-то не поддерживаемо, где-то не расширяемо. При том что задача, технически, вообще джуновая - это просто скрипт который парсит вполне простой файл и тут даже больших объёмов не предвидится.
Да, и ветки и тэги - это просто "указатели" на коммиты. И при коммите "в ветку" указатель этой ветки всегда сместится на новый коммит, без вот этого "если такой указатель указывает на последний коммит в цепочке", так как ветка всегда указывает на последний коммит. Да, могут существовать другие коммиты, которые уже были созданы из того на который указывает ветка, но текущая ветка про них ничего не знает и потому всегда смещается на новый коммит, а информация о тех "других" коммитах может быть и вовсе потеряна если для них (или их потомком) нет указателя.
Собственно git commit --ament так и работает: смещает указатель на один коммит назад, создаёт новый коммит, смещает указатель на него. Старый коммит всё ещё лежит в локальном репозитории и будет доступен для checkout и прочих манипуляций, пока не будет выполнен gc, который в том числе убивает вот такие потерянные коммиты.
Пока можно, а уже начиная с описанной в статье версии - "просто включить" уже нельзя - только ставить плагин. А сколько времени будет существовать плагин - никто не знает и гарантировать не будет.
Пока можно, а уже начиная с описанной в статье версии - "просто включить" уже нельзя - только ставить плагин. А сколько времени будет существовать плагин - никто не знает и гарантировать не будет.
Очень удобно что я могу, не отрываясь от написания кода, открыть вкладку коммитов и, допустим, быстро открыть какой-нибудь файл и глянуть там изменения.
Так и с модельным окном коммита всё это точно так же легко делается - для этого есть отдельный таб с изменёнными файлами, распределёнными по changeset-ам. Зато при модальном окне коммита diff-ы показываются не внутри открытых табов, а внутри окна коммита.
Мне казалось что в офисе нужно работать (выполнять конкретные задачи), а не просто "общаться со всеми и выяснять кто и что делал". Тем более что это выяснение всё равно не поможет в рассматриваемой ситуации.
А какая разница в офисе ты или нет, если ты не знаешь кого спрашивать? В обоих случаях ты идёшь к тому кого хоть как-то знаешь, а он направляет тебя дальше по цепочке и тут совершенно не важно как именно ты идёшь - "ногами" или "в чатике". Чаще даже "в чатике" человека проще застать, так как "ногами" его может просто не быть и ты так же пойдёшь или в чат или в почту.
Для JSON используется JSON Schema. А OpenAPI (который раньше и назывался Swagger) описывает не просто JSON, а API, причём там тело запроса/ответа не обязано быть в JSON, как и само описание спецификации.
А ещё лучше код прикладывать не скринами, а кодом:
На сколько я помню это дистиллят от полновесного
DeepSeek R1, а не его сжатая/квантизированная версия.Обычно при работе в команде влитие идёт через Merge/Pull Request, а он завязан на ветку - новая ветка это новый PR, а значит всё обсуждение из старого "теряется", оставая в старом - это как минимум не удобно.
Да и разницы между
force-пушем в свою существующую ветку и созданием новой ветки с удалением старой практически нет. Кроме того что ветка будет новая что отразится на том что завязано на имя ветки.А зачем вообще избегать
force-пуша? Это же сервер просто предупреждает о том, что он не сможет плавно переместить указатель ветки на новый коммит - то есть переместить так чтобы не потерять ни один из коммитов входящих в ветку в данный момент, а если локально проводилсяsquash,amendилиrebase, то это как раз и приводит к ситуации когда часть коммитов (про которые знает сервер) из ветки выпадают иforceпри пуше просто говорит ему "да, клиент знает что делает - терять коммиты можно".При командной работе
force-пуш в релизные ветки обычно запрещён политиками, изменять что-то в чужих в целом не принято, а с историей коммитов в своих ветках можно делать всё что угодно.Нужно найти определённую строку в нескольких столбцах: ИИ пишет ручную проверку каждого из столбцов, хотя поддерживаемей и расширяемей - сохранить индексы столбцов, надённых по регулярке и бегать по ним в цикле - при расширении списка столбцов достаточно поменять сконфигурированную регулярку вместо того чтобы добавлять в ИИ-код проверку ещё N столбцов.
Вот как раз вчера была задача "распарсить CSV", сгруппировать данные по одному столбцу и превратить 4 других в правильно сформированную ссылку.
Я вообще
Java-разработчик, но тут вроде как хорошо подходитPython- взял платный (вроде)Claudeи попросил реализовать скрипт максимально расписав задачу - потом всё равно процентов 40 переписал ибо на сколько подробно ни описывай задачу, но всё равно сделает не так как я "вижу", а где-то проще, где-то не эффективно, где-то не поддерживаемо, где-то не расширяемо.При том что задача, технически, вообще джуновая - это просто скрипт который парсит вполне простой файл и тут даже больших объёмов не предвидится.
Эта статья размещена в блоге компании Спринг АйО, а продукты выпускает JetBrains.
Если есть возможность скопировать с компа папку, то нет никакой сложности скопировать и ключи реестра.
У телеги клиент с открытым кодом - любую локальную проверку можно отключить в кастомной сборке клиента.
Да, и ветки и тэги - это просто "указатели" на коммиты.
И при коммите "в ветку" указатель этой ветки всегда сместится на новый коммит, без вот этого "если такой указатель указывает на последний коммит в цепочке", так как ветка всегда указывает на последний коммит.
Да, могут существовать другие коммиты, которые уже были созданы из того на который указывает ветка, но текущая ветка про них ничего не знает и потому всегда смещается на новый коммит, а информация о тех "других" коммитах может быть и вовсе потеряна если для них (или их потомком) нет указателя.
Собственно
git commit --amentтак и работает: смещает указатель на один коммит назад, создаёт новый коммит, смещает указатель на него.Старый коммит всё ещё лежит в локальном репозитории и будет доступен для
checkoutи прочих манипуляций, пока не будет выполненgc, который в том числе убивает вот такие потерянные коммиты.Это точно именно этот параметр?
В статье идёт речь про вот этот параметр:
А описание от
Toggle commit controlsвроде как про что-то другое ...При переключении на хэш есть неоднозначность привязки к ветке, которой нет при переключении на ветку.
Пока есть параметр
Version Control > Commit > Use non-modal commit interfaceв котором можно снять галочку.Если уже перешли на версию
2025.1 Beta, то нужно ставить плагин (ссылка на него вроде есть в статье).Пока можно, а уже начиная с описанной в статье версии - "просто включить" уже нельзя - только ставить плагин.
А сколько времени будет существовать плагин - никто не знает и гарантировать не будет.
Пока можно, а уже начиная с описанной в статье версии - "просто включить" уже нельзя - только ставить плагин.
А сколько времени будет существовать плагин - никто не знает и гарантировать не будет.
Так и с модельным окном коммита всё это точно так же легко делается - для этого есть отдельный таб с изменёнными файлами, распределёнными по changeset-ам.
Зато при модальном окне коммита
diff-ы показываются не внутри открытых табов, а внутри окна коммита.Так можно делать и с модальным окном коммита - через просмотр диффа можно открыть модальное окно в котором никто не запрещает вносить правки.
Я так и не смог перейти от модального окна коммита к тому что пришло на его замену.
В первую очередь из-за малых размеров и странной функциональности.
Мне казалось что в офисе нужно работать (выполнять конкретные задачи), а не просто "общаться со всеми и выяснять кто и что делал".
Тем более что это выяснение всё равно не поможет в рассматриваемой ситуации.
А какая разница в офисе ты или нет, если ты не знаешь кого спрашивать?
В обоих случаях ты идёшь к тому кого хоть как-то знаешь, а он направляет тебя дальше по цепочке и тут совершенно не важно как именно ты идёшь - "ногами" или "в чатике".
Чаще даже "в чатике" человека проще застать, так как "ногами" его может просто не быть и ты так же пойдёшь или в чат или в почту.
Для
JSONиспользуется JSON Schema.А OpenAPI (который раньше и назывался
Swagger) описывает не простоJSON, аAPI, причём там тело запроса/ответа не обязано быть вJSON, как и само описание спецификации.@moderator это дубликат статьи https://habr.com/ru/companies/metalamp/news/860526/ от того же автора