Здравствуйте, xvost, Вы писали:
D>>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git X>1) все твои коммиты есть в git reflog
Спасибо, всё нашёл, всё ок. 10 минут паники, позорный пост на RSDN — оно того стоило
X>2) На сервере стоит принудительно включать запрет на force push — тогда гарантированно репозиторий на сервере никто не сломает
Годно, сейчас пойду читать, как это сделать.
Здравствуйте, netch80, Вы писали: D>>почему-то появились изменённые и незакоммиченные файлы N>То есть rebase pull прошёл молча, но "появились изменённые и незакоммиченные файлы"? N>И больше ничего не делалось?
Выводы команд я не писал. Вывод rebase вот:
лог
$ git pull --rebase
remote: Counting objects: 152, done
remote: Finding sources: 100% (114/114)
remote: Getting sizes: 100% (48/48)
remote: Compressing objects: 98% (23920/24271)
remote: Total 114 (delta 93), reused 111 (delta 92)
Получение объектов: 100% (114/114), 7.38 MiB | 4.41 MiB/s, готово.
Определение изменений: 100% (94/94), завершено с 27 локальными объектами.
Из https://git.блаблабла
d07b7af..aab25a5 develop -> origin/develop
Сначала перематываем указатель текущего коммита, чтобы применить ваши изменения поверх него…
Applying: My commit message
Использую индекс для реконструкции базового дерева…
M path/to/some/source.cpp
.git/rebase-apply/patch:675: trailing whitespace.
.git/rebase-apply/patch:757: trailing whitespace.
.git/rebase-apply/patch:934: trailing whitespace.
void SomeClass::someMethod(someParams)
.git/rebase-apply/patch:949: trailing whitespace.
{
.git/rebase-apply/patch:950: trailing whitespace.
another line of code
warning: пропущено 9 ошибок в пробельных символах
warning: 14 строк добавили ошибки в пробельных символах.
Откат к применению изменений к базовому коммиту с помощью трехходового слияния…
error: Your local changes to the following files would be overwritten by merge:
path/to/another/source.cpppath/to/another/source.h
Please, commit your changes or stash them before you can merge.
Aborting
Сразу после этого я сделал git status, который мне выдал
перемещение в процессе; над aab25a5
Вы сейчас перемещаете ветку «develop» над «aab25a5».
(все конфликты разрешены: запустите «git rebase --continue»)
Изменения, которые не в индексе для коммита:
(используйте «git add <файл>…», чтобы добавить файл в индекс)
(используйте «git checkout -- <файл>…», чтобы отменить изменения
в рабочем каталоге)
изменено: path/to/another/source.cpp
изменено: path/to/another/source.h
нет изменений добавленных для коммита
(используйте «git add» и/или «git commit -a»)
N>Что-то крайне слабо верится.
Сам удивлён D>>git rebase --continue N>А это ещё зачем? Оно показало конфликт? Если нет, то какой к лешему continue? N>Если да, то почему не разобрался с тем, что в конфликте?
Нет, конфликт не показало. D>>git push D>>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git N>И пользователь, который совершенно не хочет понимать инструмент и действует на уровне "тут вылезло красненькое, я нажала и всё пропало".
Своей вины не отрицаю, но как-то довольно просто получилось выстрелить себе в ногу, не ожидал.
Здравствуйте, eskimo82, Вы писали:
D>>Консольный Git, 2.6.0 E>Неужели под виндой
Нет, OS X. Но под виндой было бы то же самое, наверно.
D>>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git E>Совет: Никогда, никогда не делай rebase пока не заучишь GitMagic наизусть на оригинальном языке.
Здравствуйте, uncommon, Вы писали:
D>>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git U>Вот что бывает, кода набиваешь команды, не имея никакого представления о том, что они делают.
Здравствуйте, koandrew, Вы писали:
S>>Кэп: гит не работает, если в команде есть хоть один человек, не изучивший мануал.
K>Вот потому он и не нужен™
После работы с такими коммерческими тулами как ClearCase, Synergy, Rational TeamConcert мне Git показался самым разумным что было изобретено в этой области. Особенно в плане написания интеграций с ним.
Здравствуйте, sergey179, Вы писали:
K>>Вот потому он и не нужен™
S>После работы с такими коммерческими тулами как ClearCase, Synergy, Rational TeamConcert мне Git показался самым разумным что было изобретено в этой области. Особенно в плане написания интеграций с ним.
Единственная причина популярности Git — социальная сеть для миллионов разработчиков Github. Всё, никаких других причин использовать сложную утилиту для поддержки разработки ядра Linux за пределами разработки ядра Linux — нет.
Здравствуйте, Dair, Вы писали:
D>и... моих изменений нет вообще. Ни одного. Пять коммитов. День работы насмарку. Отличный Git
Даже не пытался изучать гит, хоть и использовал его через студию для выкладывания кода на Гитхаб, из-за таких постов где угодно — стопицот команд, какие-то вечные проблемы, постоянные рояли из кустов в виде новых команд, которые решают старые проблемы и привносят новые. Нафиг.
Использование гита вне Гитхаба и Линукса — для меня красный флаг, команда идёт на поводу у моды, принимая технические решения.
Здравствуйте, Dair, Вы писали:
D>Выводы команд я не писал. Вывод rebase вот:
[...] D>error: Your local changes to the following files would be overwritten by merge: D> path/to/another/source.cpp D> path/to/another/source.h D>Please, commit your changes or stash them before you can merge. D>Aborting
Ага. Вот на этой точке как раз надо было остановиться и разобраться, откуда такое возникло, а что оно не смогло, явно сказало.
Если эти локальные изменения были до rebase pull, то надо было тут выполнить stash и только после этого продолжать. И после всего pull — сделать stash pop и объединять новые изменения.
Вообще тут странно вот что — по умолчанию оно запрещает делать rebase при любых локальных изменениях файлов, то есть оно вообще не вошло бы в такой процесс, потребовав stash до запуска rebase pull. Это какие-то локальные настройки, что оно проигнорировало запрет? Что за версия git?
D>Сразу после этого я сделал git status, который мне выдал D>[code] D>перемещение в процессе; над aab25a5 D>Вы сейчас перемещаете ветку «develop» над «aab25a5». D> (все конфликты разрешены: запустите «git rebase --continue»)
Хм. Насколько я понимаю, вот это сообщение и дало идею запустить rebase+continue. Оно неверно, и вот это как раз тот момент, где git явно виноват. Всё-таки надо уточнить версию, насколько она старая.
N>>А это ещё зачем? Оно показало конфликт? Если нет, то какой к лешему continue? N>>Если да, то почему не разобрался с тем, что в конфликте? D>Нет, конфликт не показало.
Конфликт не показало, но оставило в промежуточном состоянии — вот это непонятно.
Резюмирую. Надо попробовать повторить на свежей версии и максимально чистом конфиге. Если повторится и вина не в хитрых локальных опциях — это таки серьёзный повод написать problem report — на провокационное поведение. Если нет — значит, залечили и вопрос в том, почему старая версия. Личная недоработка в понимании инструмента есть, но за счёт провокации она не 100% причина. Коммиты, как я понимаю, успешно восстановлены по reflog.
Ещё в будущем в случае потенциальных сложных слияниях сохранять локальное состояние как кратковременную ветку, не принципиально, но восстанавливать с неё удобнее, чем с reflog.
Здравствуйте, Vladek, Вы писали:
V>Даже не пытался изучать гит, хоть и использовал его через студию для выкладывания кода на Гитхаб, из-за таких постов где угодно — стопицот команд, какие-то вечные проблемы, постоянные рояли из кустов в виде новых команд, которые решают старые проблемы и привносят новые. Нафиг.
V>Использование гита вне Гитхаба и Линукса — для меня красный флаг, команда идёт на поводу у моды, принимая технические решения.
Никогда не следовал моде, но после знакомства с Git решил, что среди имеющегося это лучшее, что есть. И за последние 8 лет ни разу не пожалел
Жалобы есть на все инструменты, это не фактор.
Здравствуйте, netch80, Вы писали:
V>>Использование гита вне Гитхаба и Линукса — для меня красный флаг, команда идёт на поводу у моды, принимая технические решения. N>Никогда не следовал моде, но после знакомства с Git решил, что среди имеющегося это лучшее, что есть. И за последние 8 лет ни разу не пожалел N>Жалобы есть на все инструменты, это не фактор.
Mercurial лучше — абсолютно те же самые технические возможности, но при этом более удобно. Хотя если делать всё через GUI или вообще из какой-нибудь IDE, то скорее всего разницы не увидишь.
Здравствуйте, alex_public, Вы писали:
V>>>Использование гита вне Гитхаба и Линукса — для меня красный флаг, команда идёт на поводу у моды, принимая технические решения. N>>Никогда не следовал моде, но после знакомства с Git решил, что среди имеющегося это лучшее, что есть. И за последние 8 лет ни разу не пожалел N>>Жалобы есть на все инструменты, это не фактор.
_>Mercurial лучше — абсолютно те же самые технические возможности, но при этом более удобно.
Нет, в разы менее удобно, идиотская логика на каждом углу. И не надо возражать, этот холивар давно надоел и я всё равно не соглашусь, ничего лучшего за последние лет 5 в меркуриале не случилось.
Здравствуйте, Vladek, Вы писали:
V>Единственная причина популярности Git — социальная сеть для миллионов разработчиков Github. Всё, никаких других причин использовать сложную утилиту для поддержки разработки ядра Linux за пределами разработки ядра Linux — нет.
Субъективное недовольство. Я вижу как крупные компании целиком или отделами мигрируют с коммерческих тулов на Git имея на то множество объективных причин.
Здравствуйте, netch80, Вы писали:
_>>Mercurial лучше — абсолютно те же самые технические возможности, но при этом более удобно. N>Нет, в разы менее удобно, идиотская логика на каждом углу. И не надо возражать, этот холивар давно надоел и я всё равно не соглашусь, ничего лучшего за последние лет 5 в меркуриале не случилось.
Ну естественно если речь не о технических аргументах, а о вере, то попытки убедить бесполезны) Хотя это всё как раз по профилю данного форума. )))
Здравствуйте, sergey179, Вы писали:
V>>Единственная причина популярности Git — социальная сеть для миллионов разработчиков Github. Всё, никаких других причин использовать сложную утилиту для поддержки разработки ядра Linux за пределами разработки ядра Linux — нет. S>Субъективное недовольство. Я вижу как крупные компании целиком или отделами мигрируют с коммерческих тулов на Git имея на то множество объективных причин.
Так весь вопрос в том, с чего они мигрируют. Наверняка же с древних ужасных инструментов, переход с которых на git безусловно оправдан. Другое дело, если сравнивать git с другими современными инструментами, типа mercurial/bazaar/fossil и т.п. В такой компании git выглядит уже далеко не однозначно лучшим выбором. Однако чаще всего выбирают именно его, в основном как раз из-за популярности гитхаба.
Здравствуйте, alex_public, Вы писали:
_>>>Mercurial лучше — абсолютно те же самые технические возможности, но при этом более удобно. N>>Нет, в разы менее удобно, идиотская логика на каждом углу. И не надо возражать, этот холивар давно надоел и я всё равно не соглашусь, ничего лучшего за последние лет 5 в меркуриале не случилось.
_>Ну естественно если речь не о технических аргументах, а о вере, то попытки убедить бесполезны)
Нет, не о вере. А о лени пережёвывать по 10му разу
_>Хотя это всё как раз по профилю данного форума. )))
Я никогда не воспринимал его именно как место для померяться флеймом.
Здравствуйте, netch80, Вы писали: D>> path/to/another/source.cpp D>> path/to/another/source.h D>>Please, commit your changes or stash them before you can merge. D>>Aborting
N>Ага. Вот на этой точке как раз надо было остановиться и разобраться, откуда такое возникло, а что оно не смогло, явно сказало. N>Если эти локальные изменения были до rebase pull, то надо было тут выполнить stash и только после этого продолжать. И после всего pull — сделать stash pop и объединять новые изменения.
Дело в том, что эти файлы я не трогал. Вообще.
N>Вообще тут странно вот что — по умолчанию оно запрещает делать rebase при любых локальных изменениях файлов, то есть оно вообще не вошло бы в такой процесс, потребовав stash до запуска rebase pull. Это какие-то локальные настройки, что оно проигнорировало запрет? Что за версия git?
2.6.0
Последняя сейчас 2.7.0, в понедельник обновлюсь, но не думаю, что что-то изменится. Надо просто быть аккуратным.
Про stash не забывать, да. Спасибо.
D>> (все конфликты разрешены: запустите «git rebase --continue») N>Хм. Насколько я понимаю, вот это сообщение и дало идею запустить rebase+continue. Оно неверно, и вот это как раз тот момент, где git явно виноват. Всё-таки надо уточнить версию, насколько она старая.
Не сильно старая
N>>>А это ещё зачем? Оно показало конфликт? Если нет, то какой к лешему continue? N>>>Если да, то почему не разобрался с тем, что в конфликте? D>>Нет, конфликт не показало.
N>Конфликт не показало, но оставило в промежуточном состоянии — вот это непонятно.
А я про что?
N>Резюмирую. Надо попробовать повторить на свежей версии и максимально чистом конфиге. Если повторится и вина не в хитрых локальных опциях — это таки серьёзный повод написать problem report — на провокационное поведение. Если нет — значит, залечили и вопрос в том, почему старая версия. Личная недоработка в понимании инструмента есть, но за счёт провокации она не 100% причина. Коммиты, как я понимаю, успешно восстановлены по reflog.
Всё так. Я при всех современных автоапдейтах всего забываю, что надо делать sudo port upgrade outdated, да.
N>Ещё в будущем в случае потенциальных сложных слияниях сохранять локальное состояние как кратковременную ветку, не принципиально, но восстанавливать с неё удобнее, чем с reflog.
Тут есть предыстория. Я и был в ветке. Закончил, вливаюсь в develop.
тут я в ветке my_branch
commit
checkout develop
pull
merge my_branch
(разрешение конфликтов)
add
add
add
commit
Тут в develop другие парни влили ещё два файла из заведомо других каталогов, push не прошёл.
Решил, что уже тут надо делать rebase. Ну и вот.
Гит от робота и для роботов. Способность "вернуть все взад" — принципиальная возможность систем контроля версий. Если это по каким-либо причинам не получается — на помойку.
Точнее, надо бы на помойку. На практике я понимаю, что это лучшее из того, что есть. Не знаю, как сейчас, но несколько лет назад Меркуриал был хуже.
S>Кэп: гит не работает, если в команде есть хоть один человек, не изучивший мануал.
Получаем, что при увеличении команды (а ведь Гит создавался именно для больших сообществ разработчиков) вероятность того, что он не работает, стремится к единице.
Программировать сложно. Но не программировать еще сложнее.
Здравствуйте, DSblizzard, Вы писали:
DS>Гит от робота и для роботов. Способность "вернуть все взад" — принципиальная возможность систем контроля версий. Если это по каким-либо причинам не получается — на помойку.
И эта принципиальная возможность в Git есть. Все основные объекты — файлы, деревья (читай директории), коммиты, цепочки коммитов, аннотированные теги — иммутабельные by design. Они пропадут только в том случае, если ты потерял все ссылки на них И истёк срок годности.
Здравствуйте, DSblizzard, Вы писали:
DS>Гит от робота и для роботов. Способность "вернуть все взад" — принципиальная возможность систем контроля версий. Если это по каким-либо причинам не получается — на помойку.
Оно получается.
S>>Кэп: гит не работает, если в команде есть хоть один человек, не изучивший мануал. DS>Получаем, что при увеличении команды (а ведь Гит создавался именно для больших сообществ разработчиков) вероятность того, что он не работает, стремится к единице.
Sinix неправ, или неадекватно сформулировал. Или ты слишком обобщаешь.
Да, без понимания принципов (считаем, без изучения доки) конкретный человек не будет понимать, что происходит, что делать и как удовлетворить запросы. Но это совершенно не означает, что он всё сломает у всех. При нормальной организации он всего лишь не выполнит свой личный кусок работы. А тут точно так же дальше как в любой большой группе — кто-то попал под трамвай, кто-то поймал свиной грипп, кто-то ушёл в монастырь, не доделав своего куска — но в целом работа движется.
Пример с некорректным rebase разносит только одну локальную ветку и не более того. Другие ветки живы. Другие репо у того же разработчика живы. У других разработчиков, на сервере — всё живо.
Если этот неадекват начал свои кривые результаты скидывать на сервер — в обычном push эту кривизну не примут. Если он делает forced push — от forced push есть защита.
Если он просто гонит туфту в коммитах — можно обрезать ветки обратно, можно сделать revert'ы, если полезно сохранить неудачу в истории или сложно вырезать коммит по иным причинам.
Если нужно обеспечить peer review и контроль менеджером, чтобы не было туфты, ставятся gitlab, gerrit и тому подобное, или можно работать на чистых pull from peer, сохраняя распределённую сеть. Вариантов — масса. Повторюсь, никакого конца света, никакого "не работает", и никакого в этом смысле принципиального отличия от других DVCS. Кроме одного — мне и многим другим конкретная организация git выглядит наиболее естественной, в том смысле, что больше всего действий "интуитивно ясно" и требуется минимум насилия над логикой при обучении.