LINUX.ORG.RU

Вопрос про Git. Он, правда, позволяет так легко потерять данные?

 , ,


9

7

Я тут на пробу пытаюсь парочку репозиториев перевести с привычного Mercurial на инопланетной логики Git в надежде разобраться с последним. И, ладно бы только логика работы, к ней можно привыкнуть. Но я уже несколько раз терял свои наработки с Git, чего с Mercurial не было никогда за всю историю. Пару раз терял так, что концов не найти, но вот сейчас всю цепочку отследить попробовать можно. Посему и прошу комментариев народа опытного.

Суть такая. Есть поднятый весной и так и не развитый репозиторий https://github.com/Balancer/bors-3rd-bootstrap3

Сейчас решил перекинуть туда код (со всей историей) по работе с bootstrap из ядра фреймворка, которое лежит в Mercurial на Bitbucket. Благо, есть такая прекрасная штука, как hg-git. Перенос файлов со всеми изменениями из репы в репу под Git возможен, но выглядит это чудовищно. Посему, решил вынести сперва отдельный маленький локальный репозиторий Mercurial с этими файлами, к нему подтянуть дерево Git, смержить средствами Mercurial и запушить в репу Git.

Сделать это было чуть дольше, чем написать предыдущий абзац, но работа небольшая, всё было проведено легко и непринуждённо. На GitHub'е появился объединённый модифицированный код. Всё прекрасно.

Дальше начинаются вещи непонятные. Я работал также с другой машины, там были мелкие правки (типа composer.json в корне). Решил всё объединить. Точную последовательность не помню, но, скорее всего обычные git pull && git push на другой машине.

После этого, чтобы точно убедиться, что изменения синхронизированы, провёл после git fetch (там --bare) на первой машине git push... И увидел странное:

To git@github.com:Balancer/bors-3rd-bootstrap3.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:Balancer/bors-3rd-bootstrap3.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Ну, что, Google в помощь, и первый же совет, который нахожу — воспользоваться ключиком «-f». Не вопрос. У нас же DVCS, даже если что-то не так, всегда можно откатить и т.п. Логика, привитая Mercurial'ом, ага...

Ничтоже сумняшеся, обновляю composer на другой машине и... вижу, что всех изменений, которые я переносил в эту репу нет. Удивляюсь. Вызываю git log --graph (вот почему в git по дефолту все команды такие длинные и несуразные?) — чистота. Всё в превозданном виде семимесячной давности, без переноса нового кода с основного репо.

Лезу на GitHub — и вот тут становится совсем интересно. Те изменения, что я накатывал и которые там были, теперь там отсутствуют o_O

Так вот, вопрос. Это я их не вижу, или это в Git так легко, одним движением руки можно убить безвозвратно серию коммитов с историей? o_O Если первое — то вопрос, как вернуть эти изменения. В основной репе я их уже успел прибить, но всегда можно откатить и повторить перенос. Придётся повозиться, но задача не столь сложная. Но хочется разобраться. Ибо если в Git так легко потерять изменения, то как с ним вообще люди живут?

★★★★★

Последнее исправление: CYB3R (всего исправлений: 1)
Ответ на: комментарий от anonymous

а зачем клонировать, когда есть checkout ?

checkout не тронет историю.

Любишь коллекционировать репы?

Задачу перечитай.

KRoN73 ★★★★★
() автор топика

Про то, что гит - говно и не нужен уже писали?

fenris ★★★★★
()
Ответ на: комментарий от Pinkbyte

Никакого противоречия. Пользователь Git обладает большими возможностями.
Но там где большая сила, там и большая ответственность (c).

Вот с этим ни разу спорить не буду, согласен целиком :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от Pinkbyte

То есть ключ вводим когда точно уверены что усё ок

Просто фишка в том, что опасность «-rf» у rm я представляю лет уже без малого 20, а вот в DVCS полагал, что сама идеология обеспечивает безопасность. Если бы начинал не с git, а mercurial, то, может, и не расслабился бы так. Но с mercurial привык, что в ногу он выстрелить не позволит. Соответственно, ожидал такого поведения и от других систем. Всё равно что программировать на ассемблере под DOS и на PHP под Web-сервером. В первом случае перед каждым запуском десять раз перечитаешь весь код, потому что неверный запуск — и долгий процесс перезагрузки машины, восстановления окружения и т.п. Во втором же меняешь строчку и тут же смотришь результат работы. Потому что знаешь, как не извращайся, систему оно обрушить не должно.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

а вот в DVCS полагал, что сама идеология обеспечивает безопасность

жертва собственных иллюзий .___.

anonymous8 ★★
()

а ведь на свете так много хороших и просто замечательных DVCS, это и Fossil и Veracity и Monotone и Darcs и Codeville

а холивар заводят почему-то только по Git vs. Mercurial

mm3 ★★★
()
Ответ на: комментарий от anonymous

2 чая данному анонимусу. Сделай систему которой может пользоваться дурак и только дурак захочет ей пользоваться (с)

Pinkbyte ★★★★★
()
Ответ на: комментарий от Macil

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

turtle_bazon ★★★★★
()
Ответ на: комментарий от turtle_bazon

Но я вообще не понимаю те СКВ, в которых можно что-нибудь намертво удалить. Ну не понимаю, и всё тут.

Закоммитил пароль/ключ в такую СКВ. Дальнейшие действия?

Kesha_Molchanov
()
Ответ на: комментарий от Kesha_Molchanov

Закоммитил пароль/ключ в такую СКВ. Дальнейшие действия?

меняешь пароль/ключ это же очевидно

mm3 ★★★
()
Ответ на: комментарий от turtle_bazon

а я вот всем рекламирую для домашних поделок Fossil, он конечно не такой быстродейственный на гигобайтных проектах как git, но имеет ряд интересных особенностей.

mm3 ★★★
()
Ответ на: комментарий от mm3

Он приколен, как я понимаю, для самостоятельного локального использования в первую очередь. А когда основной сервер всё равно развёрнут на Bitbucket/GitHub, то уже не так важен.

И проблема этих альтернативных систем в том, что их мало какие приложения и сервисы знают. Тот же Composer, с которым сейчас больше всего приходится работать, понимает только Git, Mercurial и Subversion. Go поддерживает Git, Mercurial, Subversion и Bazaar. И т.п. Всеми поддерживается именно Git. Многими — Mercurial, чуть реже — Subversion, но это уже не DVCS. Остальное — фоновые следы...

KRoN73 ★★★★★
() автор топика

Тебе гит человеческим языком написал:

Integrate the remote changes (e.g. 'git pull ...') before pushing again.

Неет, надо гуглить. Нагуглил опцию --force. Почитать что она делает? Зачем, в гугле плохого не посоветуют. А виноват git - парадокс.

Kesha_Molchanov
()
Ответ на: комментарий от anonymous

а зачем клонировать, когда есть checkout ? Любишь коллекционировать репы?

А это профдеформация меркуриалом. Там же нет нормальных веток. Приходится делать «ветки» в разных директориях клоном. И этот способ описан в официальном воркфлоу! Сам так делаю, когда приходится с hg иметь дело.

Deleted
()
Ответ на: комментарий от Kesha_Molchanov

Какое позднее зажигание :)

Ты правда думаешь, что столько страниц обсуждения спустя твоя мысль будет звучать свежо и ново?

KRoN73 ★★★★★
() автор топика
Последнее исправление: KRoN73 (всего исправлений: 1)
Ответ на: комментарий от Deleted

А это профдеформация меркуриалом. Там же нет нормальных веток.

Это более цивильный вариант, чем переписывание истории задним числом. См. исходную задачу.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73

сама идеология обеспечивает безопасность

git

git начал торвальдс. у торвальдса одна идеология - техническое преимущество.

anonymous
()

Integrate the remote changes (e.g.

hint: 'git >pull ...') before pushing again.

Тебе гит прямым текстом написал команду которую надо делать, а ты сделал другую с ключом "-f". Какой гит плохой!

Dudraug ★★★★★
()
Последнее исправление: Dudraug (всего исправлений: 1)
Ответ на: комментарий от KRoN73

Ты правда думаешь, что столько страниц обсуждения спустя твоя мысль будет звучать свежо и ново?

Просто видя кол-во страниц обсуждения возникает недоумение - «что тут обсуждать?». Вроде все кристально чисто, а флейма на столько страниц...

Dudraug ★★★★★
()
Ответ на: комментарий от KRoN73

А я не тебе отвечаю. Сам читай man git, советчик блин.

omich
()
Ответ на: комментарий от KRoN73

Ну пока вроде тебе никто не предлагал прочитать то, что тебе написал гит :)

Если бы ты это сделал, этой темы бы просто не было.

Kesha_Molchanov
()
Ответ на: комментарий от Dudraug

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

turtle_bazon ★★★★★
()
Ответ на: комментарий от turtle_bazon

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

С дуру можно и х** сломать.

Dudraug ★★★★★
()
Ответ на: комментарий от turtle_bazon

Поменял пароль/ключ, а эти отозвал. Или ты думаешь, один раз уйдя на сервер, его никто не успел проиндексировать?

Оже обсуждали. А если закоммитил, но на сервер не запушил?

Deleted
()
Ответ на: комментарий от turtle_bazon

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

Напишу ещё раз: единственный способ случайно потерять данные в git - это залезть руками в .git/. В остальных случаях всё легко восстановимо.

Deleted
()
Ответ на: комментарий от Dudraug

В меркуриале его можно потом выпрямить. И это хорошо. Во всяком случае, в старых версиях было. Если они тоже как гит, то плохо.

turtle_bazon ★★★★★
()
Ответ на: комментарий от Deleted

Перезабрал с сервера, вытащил дифф локального коммита, применил, пароль убрал, закоммитил, запушил.

turtle_bazon ★★★★★
()
Ответ на: комментарий от Deleted

Ну я гитом пользуюсь много, и меркуриалом не меньше. В гите случилось так, что мы потеряли свои исходники. Не плакали, конечно, но грустно было. В меркуриали при каких только извращениях такого не было. И да, в .git/ и в .hg/ ручками не лазили. Потому что некогда красноглазить.

turtle_bazon ★★★★★
()
Ответ на: комментарий от turtle_bazon

В гите случилось так, что мы потеряли свои исходники.
...
И да, в .git/ и в .hg/ ручками не лазили.

Значит в гите вы ничего не потеряли.

Deleted
()
Ответ на: комментарий от turtle_bazon

Во всяком случае, за разумное время восстановить ничего не смогли. А как время прошло, то уже и не пытались.

Даже страшно представить что вы там сделали, раз «за разумное время» не получилось вернуть обратно. Не расскажешь?

Deleted
()
Ответ на: комментарий от Deleted

Это было два или три года назад. :) Что мы там сделали - я и сам не помню. Но факт, что кривой коммит пропушил напарник, а я это вытянул и у меня тоже всё потерялось. Вот что я помню. Чтение мануалов не помогло, потому что и время поджимало, и вообще там не для людей написано. :)

turtle_bazon ★★★★★
()
Ответ на: комментарий от turtle_bazon

особенность Fossil в том, что ревизии файлов сохраняются в sqlite'ной базе данных, тоесть в одном файле, который можно положить на флешку или в дропбокс.

рядом же можно положить консольный клиент, который идёт в виде единственного небольшого файла (или пары файлов для разных платформ) и возобновлять работу с файлами без необходимости установки клиента.

эта же особенность (хранение данных в бд) позволяет легко и не принуждённо прикрутить веб интерфейс к репозиторию, что и было сделано, а также добавить ещё несколько плюшек в виде багтрекера и wiki страничек для документации.

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

ну и в качестве бонуса идёт импорт экспорт из git в fossil репозиторий.

mm3 ★★★
()

Да уже много раз писалось и обсуждалось, что гит неюзабелен для людей дальше pull/push/checkout. Как только какие серьёзные мерджи или 15 удалённых (remote) репозиториев, без SourceTree не обойдёшься. В Mercurial всё для людей и без кучи мутных ключей, которые з...ся держать в памяти.

menangen ★★★★★
()
Ответ на: комментарий от turtle_bazon

Но я вообще не понимаю те СКВ, в которых можно что-нибудь намертво удалить.

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

Мусор во время разработки имеет тенденцию накапливаться...

Например, у меня примерно такой воркфлоу: бранчим — коммитим как придется — переупорядочиваем — сливаем/разбивам — рибейзим. Плюс, широко используется amend...

Я не профессиональный программист... И тыщщу раз убеждался, лучше сделать коммит с префиксом wip, ибо вполне возможно в следующий раз смогу к нему вернуться только через несколько месяцев, и лучше он будет сидеть в апстрим-репозитории в рабочей ветке и ждать своего аменда, чем я матерясь буду разыскивать локальную копию.

Так что я в свою очередь не понимаю СКВ с физическими, неудаляемыми ветками, и без возможности править коммиты. Для профи, действительно пофиг. А для нас, партизан от программирования, гит — самое настоящее спасение.

Macil ★★★★★
()
Ответ на: комментарий от Dudraug

Тебе гит прямым текстом написал команду которую надо делать, а ты сделал другую с ключом "-f". Какой гит плохой!

Не, он все правильно сделал. При попытке пула, гит учинил бы лютый мердж и запорол бы дерево аннотациями разрешения конфликтов. А так у ТС просто повис кусок истории. Вся драма только в том что случилось это на гитхабе, где нет простой и понятной работы с рефлогом. Но я приводил ссылку на пост, где описано как разруливать такую ситуацию с помощь АПИ гитхаба.

Macil ★★★★★
()
Ответ на: комментарий от turtle_bazon

а я это вытянул и у меня тоже всё потерялось

ProGit, девятая глава. Изучить структуру базы объектов гита. Сразу всё станет понятно.

Напарник не коммит кривой пропушил, он передвинул tip рабочей ветки назад. Ты это дело вытянул, у тебя tip ветки сместился назад и добавились коммиты твоего напарника. Фактически, создался форк, с той только разницей что твоя ветка оказалась несвязанной ни с каким рефом, и для тебя «потерялась». Ссылка на твою ветку осталась в ORIG_HEAD и рефлоге. Всего лишь нужно было сделать рибейз, и отругать напарника.

Macil ★★★★★
()
Ответ на: комментарий от Macil

При попытке пула, гит учинил бы лютый мердж и запорол бы дерево аннотациями разрешения конфликтов

rebase спасет отца русской демократии.

Dudraug ★★★★★
()
Ответ на: комментарий от menangen

В Mercurial всё для людей и без кучи мутных ключей

бугага! да hg без мутных ключей и пачки расширений даже лог нормально отформатировать не может.

waker ★★★★★
()
Ответ на: комментарий от Macil

тссс.. у типичного hg-вода, на словах «передвинул tip рабочей ветки назад» происходит смещение оси вращения вселенной.

waker ★★★★★
()
Ответ на: комментарий от thesame

даже то что было unstaged?

К тому, что было unstaged, git не имеет никакого отношения.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.