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)

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

Я же жду пример, когда аналогично можно, ошибившись в одном ключике, попасть в такую же ситуацию с Bitbucker (скажем) и Mercurial.

в меркуриале редактирование истории сделано через анал. в нем нет аналога git push -f. для тех, кто не умеет читать доки, и пользуется DVCS методом научного тыка — это и к лучшему.

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

Есть хороший BitBucket - ничем не хуже гитхаба в принципе, особенно, если проект коммерческий. И работает раза в 3 быстрее Github. Github нужен чисто как соц. сеть. Типа трёпа в комментах. Всё остальное есть в BitBucket.

menangen ★★★★★
()

Вместо простыней плача Ярославны, нужно просто (один раз) понять как устроена база объектов git.

Фишка в том, что запись с блобом создается в базе объектов гита по команде git add. Если после этого файл изменился, то по git add будет создан еще один блоб. Несвязанные с деревьями блобы будут продолжать висеть в базе объектов гита, пока не включится сборщик мусора, т.е. разумный срок.

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

В твоем же случае, в объектной базе гита были (и остались) коммиты. Только по какой-то непонятной причине съехал какой-то из ref'ов. Может быть ты игрался с reset?

Далее, между тобой и гитом состоялся диалог примерно такого содержания:
Гит: Хозяин, тут, эта, такое дело... У Вас реф текущего бранча не совпадает с моим, возможно, Вы не слили последние коммиты.
KRoN73: Заткнись, тупая скотина! Я знаю лучше.

Дальше ты просто запаниковал.

Специально для таких случаев есть ORIG_HEAD и reflog.

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

Что случилось с гитхабом, мне сложно сказать. Как я понимаю, простых способов поправить ref ветки не существут. Т.е. на гитхабе неслитые коммиты пропадут, и пропадут вообще, если ты успел грохнуть локальный репозиторий. Но это не проблемы гита.

А всего-то нужно было прочитать 9-ю главу ProGit...

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

В общем, идиотский git требует перед каждым коммитом делать git add для всех директорий, где с файлами были сделаны изменения!
git add
для директорий

Cool story, bro

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

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

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

в меркуриале редактирование истории сделано через анал

А мне, как раз, требуется именно надёжное хранение истории.

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

umount с ключиком «-f»

Как это повредит мои коммиты на BitBucket?

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

У них считается, что репозитории нужны чтобы сохранять историю, а не ломать или менять её.

И мне от DVCS нужно именно это. Подделка истории — нафига?

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

htpasswd с ключиком "-c"

Это приведёт к потере данных Mercurial на удалённых репах? o_O

Читайте на что отвечаете.

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

смотря что подразумевать под словом «убить». я в первую неделю работы с hg не расставался с бэкапами, т.к. «терял» результаты работы во время pull, merge и rebase постоянно. со временем разобрался. тебе уже вроде написали, что push -f это не «rm -rf». твои коммиты никуда не деваются.

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

В меркуриале редактирование истории это вообще плохой подход.

в меркуриале много чего считается. поэтому много чего приклеено соплями, т.к. оказалось, что «плохой подход» тоже иногда нужен.

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

Например? Насколько я видел, все ненужности вынесены в плагины. Типа, хочешь выстрелить себе в ногу — поставь пистолет сам.

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

Например? Насколько я видел, все ненужности вынесены в плагины. Типа, хочешь выстрелить себе в ногу — поставь пистолет сам.

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

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

Пример неполноценных фич можно? Я просто плагином ставил только rebase, и он вполне полноценный. Во всяком случае в моём юзкейсе не возникло проблем, он позволяет избежать лишнего мержа.

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

А мне, как раз, требуется именно надёжное хранение истории.

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

В гите нет понятия «переписывание истории». Можно создать альтернативную историю. Можно грохнуть часть истории. Но переписать содержимое комита/дерева/блоба не-воз-мож-но.

Если в команде есть кривые руки, то нужно тегировать каждый чих. Например, отсмотрел «старший» код, ставит тег «Я отсмотрел здесь». После чего с репозиторием можно творить вообще всё что угодно: сборщик мусора никогда не доберется до уже отсмотренных коммитов. Главное не трогать теги, но это решается настройкой хуков.

Если бы ты поставил тег, а лучше бы сделал бранч «Я щас буду сношать репозиторй» (что вообще одно и то же, просто называется по-разному) по текущему хеду на гитхабе (через веб-интерфейс), то *никаких* я подчеркиваю *никаких* проблем не было бы вообще. Даже, если бы tip текущего бранча ушел назад, то история бы не потерялась!

Бранчи в гите не существуют физически. Это просто ссылки на текущий коммит от которого можно построить историю. И у гита хватает мозгов различать ситуации, когда нужно создавать мердж-коммиты, а когда нужно просто переписать соответствующий реф.

Если это не надежность истории, то что же ей является?

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

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

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

Он уже давно перестал быть авторитетом. И вообще, я смотрю, ему насрать на то, что наступает линуксокапец!

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

Кнут. В меньшей мере — Столлман. Кого бы еще вспомнить из ныне живущих...

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

я в первую неделю работы с hg не расставался с бэкапами, т.к. «терял» результаты работы во время pull, merge и rebase постоянно

Но как? Можешь воспроизвести? Даже при hg revert незакоммиченные изменения и то в *.orig сохранятся.А уж если оно закоммичено — то закоммичено. И чтобы изуродовать их в репе нужна весьма недюжинная цепочка действий.я в первую неделю работы с hg не расставался с бэкапами, т.к. «терял» результаты работы во время pull, merge и rebase постоянно

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

В гите нет понятия «переписывание истории». Можно создать альтернативную историю. Можно грохнуть часть истории.

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

Если в команде есть кривые руки, то нужно тегировать каждый чих.

«Машина должна работать, человек — думать». В XXI веке такой рутиной должна заниматься именно система, а не ломать свою голову пользователь.

Если это не надежность истории, то что же ей является?

Её неприкосновенность, как в Mercurial.

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

А гитхаб по-твоему не «проприетасты»? Смешно. Обе компании коммерческие и хотят твоих денег. Что в этом плохого?

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

Я о том, что на "битбакете" больше проприетастов свои "закрытые" репозитории размещают! Не хватало еще заразиться!!!

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

Эдди, ну если ты кодишь за бабки. За 700 долларов в неделю. Ты откроешь свой репозиторий всем? Чтобы потом твоё поделие спёрли и подняли конкуренты за 2 недели? Например, игру для facebook, которая приносит в день $3.000? Это рельные проекты, которые мы хостим на битбаките.

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

Так пример будет или нет. Лично я пока вижу, что для обычного разработчика его вполне достаточно.

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

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

Но как?

посредством непонимания как в hg работает merge, rebase, pull, fetch, push и т.п.

Можешь воспроизвести?

могу.

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

Я получаю зарплату. А за то, что я "кодю", я ничего не получаю! Это — побочный процесс, необходимый для моей основной деятельности!

Например, игру для facebook, которая приносит в день $3.000

Я не занимаюсь такой чепухой.

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

Нет. Что мешает новичку закоммитить со своего, не настроенного git?

и ты еще говоришь, что я троллю? :D

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

Я о том, что на «битбакете» больше проприетастов свои «закрытые» репозитории размещают! Не хватало еще заразиться!!!

я на гитхабе размещаю свои проприетарные проекты :)

waker ★★★★★
()

Мне кажется у тебя не определен грамотный workflow

Обновляться пулом, да и вообще надо примерно так:

ветку мастер не трогать

для пула переходишь в отдельную ветку:

git checkout branchnew

git pull

фиксишь конфликты (коммит при необходимости),

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

переходишь на ветку work или testing

git co work

делаешь git merge

проверяешь, тестируешь

если все ок - переходишь на ветку master:

git checkout master

git merge work

еще раз все проверяешь - не обязательно в общем уже, но регламент

еще раз синхронизируешь:

git merge work branchnew

все ок - заталкиваешь изменения на центральную репу, если она есть, предварительно сделав pull. Но лучше это делать c отдельной ветки, а повторяешь всё снова. В какой-то момент надо выбрать для синхронизации мастера.

Примерно так. Возможны вариации.

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

а какая кому разница, чего тебе достаточно?

Разница в удобстве инструмента. Если всем достаточно имеющихся в нём фич, то нет смысла добавлять новые, которые не нужны.

я потому и не хочу приводить тебе примеры

Ну ок, значит будем считать что ТС прав.

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

Я правильно понимаю, что если на первую же активную операцию «use Github’s Refs API to create a new branch pointing to that commit» с sha, взятым с последнего коммита получаю: ««message»: «Not Found»», то это значит, что на GitHub'е ничего не осталось?

Ты что-то делаешь не так. Если коммит есть в рефлоге, значит все данные на месте.

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

Нет. Что мешает новичку закоммитить со своего, не настроенного git?

что помешает новичку закоммитить в hg код, который после сборки и запуска сделает rm -rf / всем остальным девелоперам?

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

Или когда пущу работать с репой зелёного новичка.

Не стоит новичку давать все права на репозиторий. Да, и для меркуриала тоже.

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

Эталонно — это когда некая DVCS позволяет потерять все наработки одной операцией. Даже не операцией, а одним ключиком. Это очень напоминает Windows времён 95...

опиши процесс, как потерять все наработки безвозвратно. если ты эти самые наработки потер у себя локально — ты ССЗБ. если ты как-то умудрился потереть их еще и на сервере — ССЗБ^2. причем тут git?

waker ★★★★★
()
Последнее исправление: waker (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.