Не смог ответить на этот вопрос

Оба файла идентичны с точностью до байта, только время разное. Но обычно время и не влияет.

Подробными исследованиями не занимался, проверить уже ничего не получится, народу нужно работать дальше, но узнать всё равно интересно

Замечал иногда, что Гит в changes показывает "удалений 0, добавлений 0", но это всё равно вносится в изменения.

Вобщем, если не гуглить и не чатить, то лишь предположение, что можно зафорсить чек-ин файла даже без изменений.

Интересует другое типа команды: git changestype abc.cs, а в ответ получаешь, отчего файл считают модифицированным

...

вот может быть и помогло:

Run git diff --summary to check for mode changes, но это винда.

Это тоже не пробовали, но скорее всего было бы пусто

Use git diff "file" to inspect changes in detail.

Может, похожая проблема. Запушил на удалённый сервер лишние изменения в коммите. Но без пулл реквеста. Решил исправить, запушив ещё один коммит, где просто вернул взад ненужные изменения. Потом подумал, что как-то нехорошо, почитал букварь, и решил удалить последние два коммита: git reset --hard HEAD~2. Там написано, что если не пуллил это другим, то должно норм прокатить. А я не пуллил. Вместо просто удаления, эта штука сделала параллельную ветку, где обошла последние два коммита и замерджила её впереди них. Т.е. нифига не удалила, а обошла.

Правда, делал не командой в консоли, а в гуевом интерфейса для Студии, кликнув по разу по ненужным коммитам и выбрав "Reset - Delete changes (--hard)".

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

Ну старпёрские снобы, любители эмаксов и прочей консольной чепухи обязательно скажут. А нормальные люди?

Что не нужно было? Удалить коммит? Тут меня обвиняли, что я мол не разбираюсь в гите и вообще. А сами похоже дальше коммитов и пушей никуда не ушли. Удалять коммиты для современного разраба должно быть так же просто, как выпить стакана воды. Тем более, что похоже удаление коммита преобразуется в новый бранч и тут же мёрдж.

Удалять коммиты

Вы неправильный коммит запушили. Как исправлять будете?

Меня больше интересует, почему обходная ветка создаётся. Это нормальное поведение гита, или что-то пошло не так? Хотя по идее, если конечный результат одинаковый - останется одна ветка, причём та же самая, без ненужных коммитов - то пофиг, как это реализуется. Просто мне интересно. Написано одно, а делается по факту другое.

У меня схема ветки моей выглядит так. Т.е. результат такой, какой нужен - плохие коммиты теперь не попадут в финальный вариант. Но то, как это сделано, противоречит тому, как описана команда. Ты читаешь одно, видишь другое - это и смущает.

Вы неправильный коммит запушили. Как исправлять будете?

Правильный сделаем....

Меня больше интересует, почему обходная ветка создаётся.

Когда напишите конкретную команду гита в командной строке и там тоже создаться ветка, тогда можно будет и обсуждать.

Не пользуюсь студией для гита, как и командами Но что она там делает.....

Консоледрочеры, как вы выделяете куски файла с кучей изменений, которые отправляются в конкретный коммит? Если я надел много изменений, которые в один коммит не идут, и должны быть разделены, я выделяю часть для первого коммита в виде отправления этих изменений в staged. Затем делаю коммит для staged. Потом дальше выделяю, и так пока не разделю все изменения на отдельные коммиты через staged. Обычно это не больше 2-3 коммитов, чтобы сильно не запутаться. Так я могу в staged отправить от отдельных строчек файла, до челых кусков с несколькими строчками. Для этого я смотрю в визуальной утилите на все changes файла и там уже веделен каждый кусок - его можно отдельно сделать staged, а можно построчно.

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

И только не говорите мне, что вы не делаете в одном файле одновременно изменения, которые надо по разным коммитам разнести. )))

Даже безо всяких визуальных утилит - в Студии прямо в коде можно выбрать линии с изменениями, которые можно отменить или подготовить (to stage). А как в консоли я буду отдельные линии и целые куски в разных файлах выделять? Неудобно наверное?

вы не делаете в одном файле одновременно изменения, которые надо по разным коммитам разнести.

никогда, и не могу понять, даже зачем такие извращения? Сделал - закомитил

Ну вы как тот этот...

Да лучше бы объяснили зачем?

Явно что-то не то делаете.

Если есть команда, чтобы это делать, значит можно это делать. Иначе зачем нужна команда stage?

Иначе зачем нужна команда stage?

Хм, оказалось, что я даже и не подозревал, что можно стажить только части , не вижу подобного в моём UI

Ну так без нее никак, хотя чаще всего берется всё. Но иногда выбираются отдельные файлы.

Хотя есть и более интересная команда

Да, stash и stage — это разные механизмы в Git, хотя оба помогают управлять незакоммиченными изменениями.

🔹 Staging (git add / git stage)

• Подготавливает изменения для коммита.
• Изменения остаются видимыми в рабочем каталоге.
• Не мешает переключению веток, но файлы остаются в текущем состоянии.

🔹 Stash (git stash)

• Временно сохраняет изменения и очищает рабочий каталог.
• Позволяет переключаться на другую ветку без конфликтов.
• Можно восстановить (git stash pop или git stash apply) позже.

Если тебе просто нужно подготовить изменения без коммита, stage подходит. Если же нужно убрать изменения на время, но потом вернуть их — stash удобнее.

Да лучше бы объяснили зачем?
Явно что-то не то делаете.

Ну так без нее никак

Хе-хе...

Если тебе просто нужно подготовить изменения без коммита, stage подходит. Если же нужно убрать изменения на время, но потом вернуть их — stash удобнее.

Думаете, я этой туфтой гитовой буду голову забивать, выучивая все возможные нюансы? Мне просто надо было закоммитить часть кода в разных файлах после того, как я уже наделал изменений. Я поискал, как это сделать - нашёл stage. Теперь её юзаю. А stash для меня так и осталось пока неясным, как работает. Даже по вашему описанию. Я вот описание хард ресета прочитал, чтобы коммиты последние отменить, сделал, а гит через обходную ветку это сделал. Хотя нигде не было написано, что они делает это через обходные ветки. Ну да пофиг, раз результат одинаковый. Главное, что и по остальным командам так же может быть - написано одно, а реально выполняется по-другому.

Большинство разработчиков коммитят и пушат, максимум ещё пару команд знают, и нюансами по жонглированию десятками веток со стратегиями их слияния и ветвления, а также безопасного редактирования кучи веток параллельно не заморачиваются. Им бы свой код написать.

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

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

Для одного случайного раза может еще и можно понять, думал, что постоянно требуется коммитеть части файла.

Просто без stage вообще нельзя работать во многих UI, поэтому думал что речь о чём то другом.

выучивая все возможные нюансы

А не нужно ничего учить, всего то знать, когда нужную кнопу нажать.

Сидишь вот работаешь, и вдруг команда нужно срочно "это". Сохраняешь все изменения в стэш и переключаешься куда хош. Сделал что нужно, переключился назад, восстановил и работаешь дальше. Приче восстановить можно в любую ветку

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

Для одного случайного раза может еще и можно понять, думал, что постоянно требуется коммитеть части файла.

...а потом мне понравилось.