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)

Ответ на: комментарий от waker

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

hg glog?

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от KRoN73
$ hg glog
*** failed to import extension mercurial_keyring: No module named mercurial_keyring
hg: unknown command 'glog'
'glog' is provided by the following extension:

use "hg help extensions" for information on enabling extensions
waker ★★★★★
()
Ответ на: комментарий от menangen

Я логи hg смотрю не в терминале, к примеру. У меня нет проблем с форматированием :-)

я и не сомневался :)

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

Даже то что было в gitignore, лол!

git reset --hard не трогает то что в gitignore :) в отличие от prune.

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

Одна строчка в ~/.hgrc в секции [extensions]:

[extensions]
hgext.graphlog =

Если что, я встроенные плагины за криминал не считаю :)

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

ты читал то, на что ответил? я тебе процитирую еще разок:

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

waker ★★★★★
()

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

Любой косяк в локальном репозитории всегда можно откатить (даже если нет «бэкапного» репозитория). А вот перетирание коммитов в общей репе (что, собственно, и делает push -f) может привести к тому, что, грубо говоря, каждый разработчик окажется со своей версией истории в origin/master. По этому при групповой разаботке использование push -f обычно запрещают (на уровне конфигурации репы, либо на уровне договоренности)

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

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

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

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

git-push - Update remote refs along with associated objects
git-rebase – Forward-port local commits to the updated upstream head

Перевод на человеческий язык:

git-push – Upload changes from your local repository into a remote repository
git-rebase – Sequentially regenerate a series of commits so they can be applied directly to the head node

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

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

Она почти неотличима от машинно-сгеренированного текста. Фактически, за любым вопросом приходится идти в гугл или смотреть написанные кем-то другим книжки.

quantum-troll ★★★★★
()
Ответ на: комментарий от Kiborg

если читать только заголовки страниц руководства, и пытаться по ним понимать как работает git - то да, возразить тут нечего, получится белиберда. но я, все же, советую попробовать читать и остальной текст. он достаточно быстро делает понятным и то, что написано в заголовке, и все остальное тоже. я в основном по нему и изучал гит. начинать советую с gittutorial. и, что характерно, примеры push и rebase — это вообще не для новичков. т.к. в той модели использования git, для которой он создавался, push вообще практически не используется, в отличие от pull, а rebase вообще такая фича, до использования которой нужно понять и освоить многое другое. конечно, при использовании github, и подобных сервисов, где пропагандируется использовать git в стиле cvs — push нужен почти всем. но что-то мне подсказывает, что на github и туториалы свои есть, написанные для соответствующей аудитории.

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

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

для остальных в интернете есть куча альтернативных источников информации

И, вот, в итоге всплывает ключик -f и начинается эта тема...

...

Что характерно, чтобы многолетне и плодотворно пользоваться Mercurial'ом я вообще ни одной страницы документации не читал. Хватило простого примера и последующих подсказок самого hg.

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

Ну на странице про push содержимое не сильно отличается от заголовка. К слову, остальные страницы руководства написаны менее укуренным языком, чем эти две.

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

Короче, надо просто пользоваться удобным лично для себя инструментом и не париться. Я вполне понимаю преимущества гита, но они не настолько критичны для меня, как удобство и простота меркуриал.

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

Перевод на человеческий язык

Вот из-за таких вот «переводов» ТС сделал, то что сделал! Здесь как раз «человеческим языком» написано, что push при неправильном использовании сможет сдвинуть tip ветки (веток) назад (вперед) и тем самым подвесить кусок истории в воздухе (привести к появлению левых коммитов), а загрузка объектов в удаленный репозиторий может привести к формированию новых (псевдо) веток. Нужное подчеркнуть.

При особо креативном использовании можно «затереть» текущую ветку. Но конечно же, реально ничего не пропадет... Гит не записиывает дельты, как например, Darcs. Гит записывает текущее состояние, позволяя по необходимости рассчитывать дельты.

ref — это совсем не репозиторий. Реф — это ссылка на коммит, от которого разворачивается история.

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

Все «кишки гита» представлены на 1-й (одной) иллюстрации. Ссылку я уже приводил.

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

Не понял про профи и партизан, но я препочитаю копить мусор в обмен на то, что я могу всё восстановить по истории.

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

Я тебе сейчас точно не смогу сказать что произошло, но пытались и читать этот гит, который, казалось бы, интуитивно должен понять, и что-то делать и смотреть. Но ничего за ПРИЕМЛЕМОЕ время так и не получилось сделать.

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

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

Чем больше всего пользуются, о том и холиварят. Хотя не представляю как с помощью Fossil можно добиться того же что получилось у ТС. Разве что руками залезть в кишки sqlite-бэкенда и оттуда все грохнуть

Fossil is designed to keep all historical content forever

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

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

И, вот, в итоге всплывает ключик -f и начинается эта тема...

в manpages этот ключик тоже вполне себе описан. никто не виноват, что ты не прочитал доки, а пошел гуглить непонятно что.

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

«Машина должна работать, человек — думать»

У тебя не очень получается последнее.

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

никто не виноват, что ты не прочитал доки

Что значит никто не виноват? git виноват!

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

Да, ты один из очень редких людей, что способны свободно читать документацию гита. По крайней мере 99% процентов кодеров, включая меня и KRoN73 на это в принципе не способны.

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

когда я учился в школе, был у нас там учитель математики.. так вот, он на такие вещи отвечал просто — «иди в дворники».

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

Вот из-за таких вот «переводов» ТС сделал, то что сделал!

Не вижу связи. «Переводы» как раз сильно упрощают понимание манов гита.

push при неправильном использовании сможет сдвинуть tip ветки (веток) назад (вперед) и тем самым подвесить кусок истории

Хорошо бы, чтобы это было как-то специально оговорено в документации на эту команду. Потому что по краткому описанию она совершенно не выглядит опасной. Точнее, по ее краткому описанию вообще сложно понять, что происходит.

Все «кишки гита» представлены на 1-й (одной) иллюстрации

Замечательно. Теперь-то я точно разберусь в устройстве гита. Кстати, картинка ведь из документации?

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

При желании разобраться можно в чем угодно, хоть в матане, хоть в квантовой физике. Никто и не спорит. Речь о том, что документацию гита местами неплохо было бы улучшить. Только когда ты уже понимаешь гит и знаком с его терминами, эта проблема проблемой уже не кажется, отсюда и фразы вроде «не можешь — иди в дворники». К слову, с таким подходом ваш учитель математики вообще не нужен: всё что нужно, есть в учебнике и без него.

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

был у нас там учитель математики.. так вот, он на такие вещи отвечал просто — «иди в дворники»

Всё верно. Вот и я, не желая становиться профессиональным администратором Git'а стал простым программистом :)

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

документацию гита местами неплохо было бы улучшить

это было бы так, если бы не существовало кучи книг, учебников и статей, где все описано более чем доступно.

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

книги, учебники и статьи — это тоже доки. надо было их гуглить, а не push -f.

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

Замечательно. Теперь-то я точно разберусь в устройстве гита.

http://git-scm.com/book/en/Git-Internals-Git-References иллюстрация 9-4, на случай если не найдешь.

После того как воткнешь в иллюстрацию, нужно спокойно, в дружественной обстановке скурить 9-ю главу вышеупомянутой книги. Особое внимание уделить п. 9.2, 9.3 и 9.5. Они совсем небольшие. Надеюсь теперешняя молодежь не разучилась читать книги?

Точнее, по ее краткому описанию вообще сложно понять, что происходит.

4.2! Ясно же написано: обновляет рефы и соответствующие объекты. Если ты не понимаешь что такое рефы и база объектов гита, то это твои личные проблемы. Никто тебе не будет объяснять что команда copy может затирать некоторые данные. Это и так понятно из принципов построения ФС.

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

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

Сначала нужно прояснить что такое объектная база гита. Это не сложно: всего 3 (три) типа объектов... И ты удивишься насколько гит станет «интуитивно понятным».

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

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

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

Факт остаётся фактом - гит похерил код

Нет. Не похерил. Он просто послушался хозяйского окрика: «Заткнись, тупая скотина, хозяин знает лучше». Давай совсем честно: в тот момент ты даже не представлял что такое рефлог, правда?

А вообще, говорят, если оно из мусорки уйдёт

Не из «мусорки» а «будет очищен сборщиком мусора». Опять переводы на «человеческий язык»? Для этого сначала должен быть очищен рефлог. По-дефолту, это 30 дней. Можно настроить, чтобы рефлог не очищался никогда. Гибко. С точностью до индивидуального рефа.

Вообще же, воркфлоу предполагает, что каждый разработчик, как минимум, работает в своей ветке. А лучше всего, заводит свою ветку под конкретную задачу. Как раз именно *поэтому*. Работали бы так со своим коллегой, получили бы в итоге косой master, кривизна которого вылечилась бы одним резетом. Но мы ж, крутые. Нам воркфлоу не писан...

Только гит-то тут причем?

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

Нет. Не похерил. Он просто послушался хозяйского окрика: «Заткнись, тупая скотина, хозяин знает лучше». Давай совсем честно: в тот момент ты даже не представлял что такое рефлог, правда?

Ну по факту гит похерил. Да, по команде коллеги, но гит. Сравним как ведёт себя меркуриал: «Да, хозяин, херня какая-то, но вот вам новая рабочая копия без хреновин, а хреновины вон там лежат». Гит же хреновины куда-то схомячил и просто так его это отдать не получилось.

Можно настроить, чтобы рефлог не очищался никогда.

Можно. Всё можно. Вопрос не в том, что можно, а как есть и с чем приходится сталкиваться.

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

Для меня это звучит так, что людям надо выбирать работать так, как удобно гит, а не так, как это удобно людям.

Только гит-то тут причем?

Как раз и при том.

turtle_bazon ★★★★★
()

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

Всех кто в этом тредике травит Крона, одобряю

hizel ★★★★★
()

Выросло поколение хипстеров, которые кроме деревянной модели CVS ничего учить не хотят, но какого-то черта приперлись в git (потому что Гитхаб — это моднявенько, коммитики друзяшкам на стеночку можна кидать, пулл реквестики со смайликами). А потом жалуются, что гит из-за своей веры в человечество зря не принял их за идиотов и дал сделать то, что ему приказали.

И да, выросшим хипстором можно быть в любом возрасте.

unlog1c ★★★
()

Ну просто при переходе с hg на git надо ОДИН РАЗ осознать, что в гите нет ВЕТОК в понимании hg. Там есть только указатели на концы веток. И их можно удалять, переименовывать и перемещать, как вздумается. Что на самом деле очень удобно, но естественно, при желании позволяет въ**ать всё содержимое репозитория.

Сообщение «non-fast-forward» как бы и означает то, что твоя ветка либо старее, чем то, что на сервере, либо ушла куда-то вбок, т.е. при перезаписи что-то удалит. По идее надо было почитать что оно означает, а не х**ачить -f не думая.

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

Та ну. Я сначала с svn тоже на hg перешёл и тоже считал что git наркоманский. А потом всё равно на git ушёл, когда hg достал тормозами, кривым форматом репозитория, неудобством переписывания истории, меньшим удобством работы в консоли и т.п.

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

Ибо распределённое использование mercurial и есть самая надёжная система бэкапов. И я наивно полагал, что это суть DVCS подхода вообще.

Действительно, очень наивно. Суть DVCS - верифицирующая, версионная, распределённая файловая система. Т.е. - git.

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