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

Ты по незнанию либо намерено при помощи ключика „--force“ у git создал себе проблему но виноват во всем почему-то вовсе не ты а git. Ок.

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

при помощи ключика „--force“ у git создал себе проблему

Вообще не понятно как при «push» команде можно испортить исходный репозиторий из которого выталкиваются изменения, он же фактически readonly по логике должен быть, а все изменения только там куда делают «push».

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

Вообще не понятно как при «push» команде можно испортить исходный репозиторий из которого выталкиваются изменения, он же фактически readonly по логике должен быть, а все изменения только там куда делают «push».

Я так и не распарсил весь порядок его действий… Но видимо как-то все-таки можно!

init_6 ★★★★★
()

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.

Тут он как бы явно намекает что нужно делать
И довольно понятно что не push --force

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

Просто ТС не умеет читать на английском, вслепую использует непонятные комманды, не имея представления, что они делают. А виноват инструмент.

anonymous8 ★★
()

Что-то явно пошло не так с гитом там. Где-бы сейчас была разработка ядра с такими проблемами целостности? Думаешь Линус ерунду подсунул?

Тренируйся вон... на кошках! (c)

Гит очень хорошо умеет работать с ветками. (c)

Посмотри фильм про гит с Линусом (есть с переводом отличный фильм)

За все время, был такой замеченный косяк гита:

function a()
{
  //code a...
}

function b()
{
  //code b..
}

После правок почему-то исчезла часть:

  //code a...
}

function b()
{

И соответственно //code b.. встало на место code a

Может, сам накосячил, но после этого стал делать коммиты «после каждого чиха» + тэги, ветки + тесты по возможности

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

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

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

Это из категории «угадал всё буквы, не смог назвать слово». Я понял все фразы целиком, но в них нет инструкции о порядке действия. Чём, кстати, опять же, хорош hg - тот ещё в сложных ситуациях и подсказки делает.

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

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

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

Чего pull не сделал-то?

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

Чего pull не сделал-то?

0_0 а как тогда потом git обсирать?

init_6 ★★★★★
()

только взял боец гитару, сразу видно, гармонист

thesame ★★★★
()

Не распарсил последовательность действий, но автор эталонный ССЗБ

maloi ★★★★★
()

Решил всё объединить. Точную последовательность не помню

Не пора ли на пенсию?

anonymous
()

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

ты еще первый попавшийся однострочник на перле так запусти.

waker ★★★★★
()

Попробуй ребейз на своей машине. Там покажет в каком месте история корявая

git pull --rebase

Если все не решится простым способом, то

git rebase --abort
git branch saved_master

И потом с помощью git cherry-pick (или чего-то подобного) переноси коммиты, которые считаешь «пропавшими» на локальный мастер:

# git checkout master # если не на мастере
git fetch
git reset --hard origin/master # приводим локальный мастер в соответствие с удалённым
# ACHTUNG, ALARMA, ATTENTION: все измененные незакоммиченные файлы будут утрачены НАВСЕГДА. Рекомендую воспользоваться git stash для сохранности

# добавляем "пропавшие коммиты"
git cherry-pick saved_master~2 # третий последний коммит
git cherry-pick saved_master # последний коммит
# итд

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

Все уже поняли, что ты фанат mercurial и git использовать не собираешься.

а что Вы таки имеете против ртути?

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

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

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

Меркуриализмом называется общее отравление организма

а теперь свяжи это с mercurial, шутник :)

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

как я понял, единственное, из-за чего я не потерял данные в этой истории — то, что не запускался gc?

GC удаляет неиспользуемые объекты старее двух недель (по умолчанию, настраивается). Если включен reflog (а это мегаполезная штука), то всё его содержимое доступно и легко восстановимо в течение ЕМНИП 90 дней (тоже настраивается при необходимости).

Deleted
()

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

Да.

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

вобщем ты неосилятор и не осилил больше одной системы версий. только зачем об этом писать в каждом посте?

anonymous
()

Тебе же английским по терминалу сказали:

hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart.

ты не сделал мерж изменений в удалённом репозитории на текущий мастер.

А потом с ключиком -f ты вынес текущий head заменив его своим.

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

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

Dark_SavanT ★★★★★
()

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

Давеча ввел у себя в хомяке rm -rf * и, таки, шо ви думаете?!

Так вот, в гите от такого спастись в разы легче, чем после rm -rf и тебе уже показали в первых комментариях.

А любые команды, которые позволяют использовать «силу», должны быть использованы с осторожностью.

//хотел еще с утра ответить, да завалило на работе ;)

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

pull в bare не работает, а fetch я делал

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

Вот в этом тоже разница. Про Mercurial я тоже ничего не читал. Но за последние 6 лет много тысяч коммитов в десятке проектов. Часто со сложной разработкой с десятка конкурентных репозиториев. И ни разу ничего не терялось. Соответственно, я полагал, что это серебряная пуля DVCS вообще, а не одного Mercurial. И поэтому перенёс такое же отношение на git. Оказалось, фигушки, git весьма чувствителен к весьма простым действиям пользователя. Что для меня несомненный минус. Поскольку я разделяю принцип IBM «машина должна работать, человек — думать». В XXI веке системы должны спокойно переносить ошибки пользователя. Принцип GIGO осуждался уже в 1980-е годы прошлого тысячелетия :)

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

А что про Форт? Первую программу на нём я написал в 1991-м, последнюю в 2007-м :) Так что баек знаю множество. Ты про какую?

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

Вот именно потому люди и начинают использовать DVCS. В Mercurial я после заливки данных на другой репозиторий, могу извращаться с локальными данными как угодно. Я всегда могу вернуть старые.

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

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

+1.

Алсо, я когда выбирал какую DVCS изучать (Hg или Git), после прочтения вот этой и этой статей выбрал Hg, как более простую в работе систему. А когда начал работать с patch queues, понял, что для меня это просто идеальный инструмент.

Единственный потенциально существенный минус Hg, на данный момент — нормально работать с репозиторием, в котором есть файлы с именами, содержащими не-ASCII символы, можно только из одной ОС: либо win, либо lin. Но у меня все имена файлов как раз в ASCII, да и работаю я все время из линукса. Хотя, вроде бы какие-то работы в эту сторону идут, интересно чем summer of code закончился.

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

Вот в этом тоже разница. Про Mercurial я тоже ничего не читал. Но за последние 6 лет много тысяч коммитов в десятке проектов. Часто со сложной разработкой с десятка конкурентных репозиториев. И ни разу ничего не терялось. Соответственно, я полагал, что это серебряная пуля DVCS вообще, а не одного Mercurial. И поэтому перенёс такое же отношение на git. Оказалось, фигушки, git весьма чувствителен к весьма простым действиям пользователя. Что для меня несомненный минус. Поскольку я разделяю принцип IBM «машина должна работать, человек — думать». В XXI веке системы должны спокойно переносить ошибки пользователя. Принцип GIGO осуждался уже в 1980-е годы прошлого тысячелетия :)

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

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

Это неверный пример. Если у меня есть полный контроль над хранилищем, я могу сделать rm -rf и создать новый репозиторий с нуля — тоже своего рода редактирование истории, и никакие phases не спасут.

Имеет смысл рассматривать редактирование истории на удаленном публичном сервере при помощи имеющихся в VCS средств. Вот тут mercurial сделать ничего не даст, а Git, видимо, может и так.

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

ППКС, Линус тот ещё извращенец.

Что самое характерное, от других он требует юзер-френдли, а сам делает красноглазое говно :3

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

А вот mercurial вполне является.

Mercurial тоже не является. Твои попытки доказать обратное только сильнее убеждают в том, что ты не до конца понимаешь, что это за инструменты. И то, что у тебя с mercurial ещё не было факапов - нихрена не значит, потому что у любого человека всё бывает хорошо ДО первого факапа.

Но вместо того, чтобы спокойно принять советы более опытных в этой сфере товарищей, ты упираешься рогом.

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

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

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

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

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

Если к удаленному серверу есть доступ — данные восстановить не проблема

Почему тогда в столь многостранично теме получилось восстановить данные только локально, но не на GitHub'е?

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

Выше в теме были советы и ссылки. Это не сработало.

И ты не с той стороны заходишь. Тут стоит вопрос восстановления. Да ещё реально сложный вопрос (можно восстановить или нет — в этом контексте уже вторично, хотя тоже важно).

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

Было утверждение, что Mercurial в этом плане не лучше и не безопаснее, чем Git. Вот мне и интересно практическое доказательство. Чтобы на эти грабли нечаянно не наступить. Ибо я жду от DVCS возможности всегда легко вернуть старые данные. Даже когда я буду работать пьяный и не выспавшийся. Или когда пущу работать с репой зелёного новичка. Для меня сохранность данных — главное. Можно сказать, больной вопрос. Я потому так на Git и взъелся, что он на больную мозоль наступил :)

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

1. Вопрос про Git. Он, правда, позволяет так легко потерять данные? (комментарий)

Вот это странно, т.к. через сайт коммит доступен. Но это проблемы удаленного хранилища, к которому нет нормального доступа. А не git-а.

2. Я же про Mercurial спрашиваю.

Тут ничем помочь не могу, hg не знаю.

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