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)

Это не баг, это фича.
Люди читают маны или хотя бы хелпы перед копипастой гугля в консоль.

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

не до конца понимает

это очень толерантно с твоей стороны :)

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

VCS явняется частным случаем DVCS

Теоретически да, на практике же...

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

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

ну да, в случае меркуриал -f не надо писать. это я по ошибке написал. суть от этого не меняется.

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

если пушнуть на битбакет — хрена лысого ты достанешь, а не старые данные

Я с самого начала просил привести такой пример. В ответ — пока одни слова. И, да, на Битбакете сейчас штук 40 репозиториев, самому старому — скоро 7 лет. И ни разу ничего не пропадало, хотя force-операций было огромное множество в истории.

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

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

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

Я с самого начала просил привести такой пример.

ты просишь привести пример использования фичи hg, которой в нем нет. и это плохо, что ее там нет. и никого не волнует твое мнение, что эта фича «вредная», т.к. долбоклюи теряют ref'ы, и вместо восстановления делают rm -rf.

понимаю, что твоя извилина не позволит тебе понять, что на самом деле произошло, но попробую объяснить еще раз. то что ты сделал — практически равносильно удалению симлинк(ов) на файл(ы). сами файлы были на месте, пока ты сам их не похерил.

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

И, да, на Битбакете сейчас штук 40 репозиториев, самому старому — скоро 7 лет.

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

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

Крон, ты умный мужик, я обожаю читать твои комментарии на ЛОРе. Пожалуйста, перестань нести тупняк в этом треде. Ты реально фигню несёшь. То, что ты смог выстрелить себе в ногу - в этом нет вины дробовика. В этом просто твой недосмотр. А Git - наиотличнейший инструмент.

С уважением. Всех благ тебе.

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

Эдди, не ожидал от тебя такого ниасиляторства.

если делаешь hg comm, получаешь коммит со всеми изменениями, кроме новых файлов

-a

git rm еще и физически удаляет файл

--cached

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

у меня это xcode делает сам, но вообще commit -a решает

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

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

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

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

у меня это xcode делает сам, но вообще commit -a решает

что один, что второй - забиваете гвозди ноутом
коммитить нужно часто и добавлять в коммит токлько файлы, которые НЕОБХОДИМО залить в репу, а не всё подряд что было изменено

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

Если коммитить часто, зачем вообще staging area? Поправил, закоммитил. Мы же не виноваты, что Линус у себя разводит помойку в рабочем каталоге.

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

Поправил, закоммитил.

а если фичу новую 3 недели вкручиваешь? в конце один коммит сделать?
по ходу ты не понимаешь git

q11q11 ★★★★★
()

Тред не читал. Reflog. Ну и утенок, пусть и старый.

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

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

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

а если фичу новую 3 недели вкручиваешь? в конце один коммит сделать?

В идеале да. Но гитфанбои не слышали ни про mq, ни про stgit.

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

В идеале да.

угу, только вот в конце шестого дня третей недели винт летит / проц горит / любой другой вариант
и получается что почти 3 недели разработки коту под хвост

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

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

bj
()

Лень вникать в суть проблемы и читать этой большой тред. Но может быть вот что поможет. Надо в конфиге bare-репозитария запретить перетирать дерево так:

[receive]                                                                                                                                                                
        denynonfastforwards = true                                                                                                                                       
        denyDeletes = true     

denyDeletes - Это еще и запрет удаления remote веток(чтобы не удалили и не залили под таким же именем). Тогда дерево никто не перетрет.

После перехода c svn на git пока мы у себя это не сделали, переодически кто-то правил дерево центральном в удаленном репозитории. Все работают из IDE eclipse и кого-то стояла галочка с разрешением перетирать, а у кого-то нет. В итоге вася делал pull (rebase=true) и петя делал pull (rebase=true)..Потом вася делал push, а петя своим push перетирал комиты васи..Это и все можно делать на дефолтной настройке..Правильно или нет - это вопрос философский, нашей команде такое не подходило, и мы запретили это.

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

Хочешь я тебе про нуклеосинтез в звездных ядрах расскажу?

Расскажи мне про спектральные классы. Особенно интересуют те, что вне Главной Последовательности, всякие красные и коричневые карлики.

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

Потом вася делал push, а петя своим push перетирал комиты васи..

git pull --rebase ну вообще никак не приводит к перетиранию чужих коммитов (1), как и push (2), и вообще git коммиты не удаляет, а создает новые (3). думаю, что у вас что-то совсем другое происходило.

Это и все можно делать на дефолтной настройке..

чето я не замечал, чтобы в эклипсе по-дефолту была включена интеграция с git (4). но я юзаю только adt bundle.

итого, насчитал 4 штуки 4.2.

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

Раз уж такая пьянка: реально ли слить вместе два или больше коричневых карлика с целью получения более массивной работающей звезды?

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

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

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

Вполне. Только вероятность такого события ниже, чем столкновение пары нейтрино!

Да, и еще: я хочу извиниться за те оскорбления, которые я когда-либо высказывал в твой адрес

Не помню такого ☺

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

А чем плох bitbucket?

Битбакет огорожен.

Bitbucket всем хорош. Особенно наличием бесплатных закрытых репозиториев. Один минус существенно снижает его шансы — нет такой развитой инфраструктуры, в т.ч. социальной, как в GitHub.

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

Особенно наличием бесплатных закрытых репозиториев

Вот я и говорю — огорожен. Правда, на гитхабе тоже огродки есть, но не столь явные.

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

Вот я и говорю — огорожен

В этом контексте — тогда это только в плюс :) Я ж не буду код каждого заказчика в открытый доступ выкладывать. А держать свои репозитории мне уже несколько лет как надоело. Зачем напрягаться, когда готовое есть? :)

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

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

Старпрог начинает звереть, когда видит «сопли» в виде «по коммиту на каждый Ctrl-S», и я с ним совершенно согласен. Хуками, как с codestyle, этот случай не ловится.

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

Какое замечательное слово - «старпрог».

Но лично я начинаю звереть от прямо противоположного - когда человек сделал какую-то фичу и, не закоммитив, начинает что-то лепить дальше. В результате часто оказывается, что откатиться при необходимости просто некуда. Начинаешь его спрашивать «ПОЧЕМУ?», а он говорит - «а зачем коммитить недоделанную программу». Особенно этому подвержены программисты с опытом, которые ранее не работали с VCS.

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

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

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

Это уже перебор. В большом проекте ты в мусоре утонешь.

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

А с моей точки зрения закрытые репы — зло.

Всё зависит от того, для чего они применяются.

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

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

А с моей точки зрения закрытые репы — зло.

И что, у тебя совсем нет внешних приватных ресурсов? Тогда ты уникум :) Но, скорее всего, это не так...

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

И что, у тебя совсем нет внешних приватных ресурсов?

Нет. Совсем. То, что я не хочу палить, я не выкладываю во всякие "облачные" сервисы. Знаем мы, насколько они "закрытые", ога, ога...

Но это касается фоточек/видео и документации, которой пока еще не время быть открытой. Все остальное вполне себе болтается в открытом доступе.

Eddy_Em ☆☆☆☆☆
()

git log --graph (вот почему в git по дефолту все команды такие длинные и несуразные?)

Ага, давай ещё расскажи-ка как тебе удобно пользоваться hg log без PAGER'а, как он красиво гадит в терминал всю историю проекта.

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

Нет. Совсем. То, что я не хочу палить, я не выкладываю во всякие «облачные» сервисы.

А на счёт, скажем, поделиться с узким кругом друзей?

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