Здравствуйте, 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.cpp path/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 лет ни разу не пожалел
Жалобы есть на все инструменты, это не фактор.

Здравствуйте, Sinix, Вы писали:

S>Кэп: гит не работает, если в команде есть хоть один человек, не изучивший мануал.

Менее радикальный подход — пользоваться гитом через GUI, а не командную строку.

Здравствуйте, 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. Ну и вот.

Здравствуйте, Sinix, Вы писали:

Гит от робота и для роботов. Способность "вернуть все взад" — принципиальная возможность систем контроля версий. Если это по каким-либо причинам не получается — на помойку.
Точнее, надо бы на помойку. На практике я понимаю, что это лучшее из того, что есть. Не знаю, как сейчас, но несколько лет назад Меркуриал был хуже.

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 выглядит наиболее естественной, в том смысле, что больше всего действий "интуитивно ясно" и требуется минимум насилия над логикой при обучении.