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)

Это я их не вижу, или это в Git так легко, одним движением руки можно убить безвозвратно серию коммитов с историей?

Единственный способ «поломать» git - это руками залезть в .git/. В остальных случаях всё всегда можно вернуть обратно. Смотри в сторону git reflog и git reset.

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

Смотри в сторону git reflog

$ git reflog
8909780 HEAD@{0}: clone: from /var/www/repos/bors-3rd-bootstrap3.git



и git reset.

Пустой вывод, ничего не происходит.

Собственно, можешь утянуть репо с GitHub'а, он крошечный.

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

Да, это я вводил в позднем клонировании. В bare, откуда я пушил всё, git reflog даёт пустой вывод, git reset ругается «fatal: mixed reset is not allowed in a bare repository».

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

Да, прочитать четыре страницы прогит гораздо сложнее, чем накатать полотенце текста.

Сразу видно, программист на пхп.

git gc --prune=now

не забудь.

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

Это нужно делать на том репозитории, который ты сломал. И до того, как сборщик мусора удалит «ненужные» коммиты.

Deleted
()

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

ССЗБ.

это в Git так легко, одним движением руки можно убить безвозвратно серию коммитов с историей?

Да. Но не совсем безвозвратно. По идее, если сборщик мусора еще не отработал, можно восстановить цепочку коммитов по известному хешу.

Ибо если в Git так легко потерять изменения, то как с ним вообще люди живут?

Команда «rm -rf» тоже позволяет легко потерять данные. Как же с ней люди живут?

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

Это нужно делать на том репозитории, который ты сломал. И до того, как сборщик мусора удалит «ненужные» коммиты.

Этого репозитория уже не осталось. Объединял я во временном репозитории, после push'а на GitHun, убедившись, что данные были успешно отправлены, временный каталог я стёр. Также полные данные были в другом локальном bare-репозитории, с которого я разворачивал клон для composer — всё было на месте.

Хочешь сказать, что, всё же, убить данные с помощью Git так легко? И что, раз я грохнул тот временный каталог, мне мои данные (которые, повторюсь, были уже положены на удалённый сервер!) больше не вернуть? o_O

В том же Mercurial, если данные были залиты в сторонний репозиторий, они там так и останутся. Даже локальные не закоммиченные данные при откатах сохранятся в *.orig файлах.

Вот даже эти файлы, что я грохнул, спокойно лежат в предыдущих ревизиях на Bitbucket: https://bitbucket.org/Balancer/bors-core/commits/f49991a5f93bac6bd392cabd3a0d...

Если с Git всё так печально, то я вообще в недоумении.

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

ССЗБ

Для меня DVCS — это по определению надёжное версионное хранилище.

Да. Но не совсем безвозвратно. По идее, если сборщик мусора еще не отработал, можно восстановить цепочку коммитов по известному хешу.

Ну и как узнать этот хеш? Временный репозиторий, где проводил слияние, уже убит, но bare, откуда пушил на GitHub — жив.

Команда «rm -rf» тоже позволяет легко потерять данные. Как же с ней люди живут?

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

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

hg-git

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

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

ты так сделал?

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

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

Её работа была отделена от GitHub'а двумя стадиями. Да хоть rm -rf пусть делает — при чём тут пропажа данных в двух не связанных с ней репах? Ведь коммиты были на GitHub в нормальном виде.

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

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

— Клонирование с GitHub в bare

— Клонирование с bare в mercurial

— Слияние в mercurial

— push из клона в bare

— push с bare на GitHub

— проверка — клон из bare в composer. Все файлы были на месте локально. Показывались удалённо на GitHub

— Дальше — объединение с данными второй машины, на которой не было никакого hg-git. Всю последовательность не помню, но там не было ничего хитрого — git fetch в тамошнем bare, git pull с bare в обычном клоне, слияние, потом git push в bare, потом git push в GitHub. На этом моменте на GitHub всё ещё были обновлённые файлы, я проверял, как обновлялись данные в composer

А вот дальше пошла фигня. Снова на первой машине, тут уже цепочка в терминалке до сих пор висит. Сперва я запустил скрипт полного обновления bare-репозиториев, который делает для git обычный fetch. Результат:

From github.com:Balancer/bors-3rd-bootstrap3
 * branch            HEAD       -> FETCH_HEAD

Потом запустил скрипт, который по списку реп пушит изменения из bare обратно на github/bitbucket (это чтобы точно не забыть закоммитить какие-нибудь изменения — репозиториев больше десятка). И вот тут выскочило:

fatal: The current branch master has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin master

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

$ git push --set-upstream origin master
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.

$ git push -f origin master
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:Balancer/bors-3rd-bootstrap3.git
 + 573f69d...8909780 master -> master (forced update)

После этого я обновил composer. С удивлением увидел пропажу файлов. Но локально-то фигня. Заглянул на GitHub и только тут, увидев отсутствие только что бывших там файлов, вдруг мелькнула мысль, а вдруг в Git всё не так безоблачно с сохранностью/восстановлением данных, как Mercurial. Дальше:

$ git log
commit 8909780ee1e15d89133b074d4b350e341fdab73e
Author: Balancer <balancer@balancer.ru>
Date:   Tue Sep 23 05:04:30 2014 +0400

    ++

commit 51bac6f052f5ece1d8ed4482b527148e62c1ae75
Author: Balancer <balancer@balancer.ru>
Date:   Tue Mar 18 02:49:00 2014 +0400

    ++

commit ecef9e2f27862209958bc009ad765e885268e230
Author: Balancer <balancer@balancer.ru>
Date:   Tue Mar 18 02:33:40 2014 +0400

    up

commit 6f8c9ad96c2ce55d688d27583974e13db5fe01a8
Author: Balancer <balancer@balancer.ru>
Date:   Tue Mar 18 02:31:45 2014 +0400

    Init

И вот тут-то я и заподозрил, что моих файлов я могу больше не увидеть. И что Git не обеспечивает такого уровня безопасности данных, как Mercurial. И завёл сабжевую тему.

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

LMGTFY

http://www.objectpartners.com/2014/02/11/recovering-a-commit-from-githubs-reflog/

И что Git не обеспечивает такого уровня безопасности данных, как Mercurial. И завёл сабжевую тему.

То есть mercurial не позволяет админам переписывать историю в удалённом репозитории? Ок, так и запишем.

Deleted
()
Ответ на: LMGTFY от Deleted

То есть mercurial не позволяет админам переписывать историю в удалённом репозитории?

Нет (или по крайней мере я не знаю такого простого способа). Что и обеспечивает сохранность данных и истории.

LMGTFY

Сейчас посмотрю. Но количество операций и степень ручной работы поражают.

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

LMGTFY

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

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

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

Эталонно.

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

Эталонно

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

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

Нет (или по крайней мере я не знаю такого простого способа). Что и обеспечивает сохранность данных и истории.

Гораздо интереснее есть ли возможность так же просто вернуть всё обратно после случайного обнаружения «непростого способа» =).

Сейчас посмотрю. Но количество операций и степень ручной работы поражают.

Всего две команды:

git reflog
git reset $HASH
Но для этого нужен прямой доступ к репозиторию, которого в случае гитхаба ни у кого (кроме админов гитхаба) нет. Они его заменили на интерфейс через api.github.com. Возможно конкретно для гитхаба есть что-то более простое, но я не знаю. Я просто открыл первую ссылку из гугла.

P.S. Если опция называется "--force", то перед применением следует читать в документации что именно она делает =).

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

Эталонно — это когда некая DVCS позволяет потерять все наработки одной операцией.

Я не в курсе, что ты там потерял, но это как раз не эталонно. Ибо

Это очень напоминает Windows времён 95

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

P.S. Если опция называется "--force", то перед применением следует читать в документации что именно она делает =)

Да не вопрос. Просто я на Mercurial привык, что всегда можно откатить ошибочное действие. Вот и не ожидил от Git такого небрежного отношения к данным.

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

В общем, как я понял, данных уже не вернуть. И в любом случае, с системой, которая так непринуждённо позволяет эти самые данные терять — мне не по пути :) Вернул удалённые файлы в основном Mercurial-репозитории, добавил к тому, что было, и перевёл всё на Mercurial.

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

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

Просто я на Mercurial привык, что всегда можно откатить ошибочное действие.

Да не вопрос. В git тоже всегда можно откатить ошибочное действие. То, что в гитхабе не предусмотрели удобного способа для конкретно твоего случая - это не проблема гита.

Вот и не ожидил от Git такого небрежного отношения к данным.

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

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

В git тоже всегда можно откатить ошибочное действие.

Но как? Тема для того и заведена.

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

Так у меня и локальный bare есть, в котором эти же данные были. Как из него поднять? Если сделать клон с bare и взять хеш с GitHub (а как этот хеш получить, когда GitHub нет, кстати?), то по reset вываливается:

$ git reset b6f485e1f2e1c673c2007eeae1a125977f1188fb
Unstaged changes after reset:
D       classes/bors/layouts/bootstrap3.php
D       classes/bors/layouts/bootstrap3/breadcrumbs.inc.php
D       classes/bors/layouts/bootstrap3/dropdown.php

И больше ничего не происходит.

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

До сего дня я фанатом mercurial не был :) Я стал его фанатом, только увидев, с какой лёгкостью теряются данные в git и как нелегко (если возможно) добраться до этих данных.

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

Так у меня и локальный bare есть, в котором эти же данные были.

Можешь его выложить куда-нибудь?

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

Оно:

commit 573f69d615b6741380eacb373d323a324c1e9bc8 (HEAD, origin/old-head, old-head)
Merge: 8909780 df23454
Author: Balancer <balancer@balancer.ru>
Date:   Wed Oct 1 02:35:37 2014 +0400

    merge

commit df2345458ff8454c7d70aa9f82ac3d77eb5a49f0
Author: Balancer <balancer@balancer.ru>
Date:   Tue Sep 30 06:43:58 2014 +0400

    Работа над унификацией шаблонов тем и компонентов шаблонов.

 classes/bors/layouts/bootstrap3.php             |  1 +
 classes/bors/layouts/bootstrap3/navtabs.php     |  5 +++++
 classes/bors/layouts/bootstrap3/navtabs.tpl.php | 11 +++++++++++
 3 files changed, 17 insertions(+)

commit bd9acf44435babbab18152d1821acd041d99d666
Author: Balancer <balancer@balancer.ru>
Date:   Sun Sep 28 04:42:33 2014 +0400

    Рефакторинг и доработка нового механизма стилей. Поддержка .inc.css

 classes/bors/themes/bootstrap3.php | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

commit 1af5198b1aced43e53af72f30bc1d8814ce4f2be
Author: Balancer <balancer@balancer.ru>
Date:   Tue Sep 23 15:44:05 2014 +0400

    Для вложенных так?

 classes/bors/layouts/bootstrap3/dropdown.php | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 8909780ee1e15d89133b074d4b350e341fdab73e (origin/master, origin/HEAD, master)
Author: Balancer <balancer@balancer.ru>
Date:   Tue Sep 23 05:04:30 2014 +0400

    ++

 composer.json | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

commit 4078730aeebedb1c814bdd206a32a640f2b0cef3
Author: Balancer <balancer@balancer.ru>
Date:   Tue Sep 23 04:44:47 2014 +0400

    Пока не обросло legacy, меняем название templates в отношении шаблонов страниц на themes.
    
    Плюс right_menu_links теперь называется side_menu.

 classes/bors/themes/bootstrap3.php                 |  14 +++
 classes/bors/themes/bootstrap3.tpl.php             | 102 +++++++++++++++++++++
 classes/bors/themes/bootstrap3/breadcrumbs.tpl.php |  18 ++++
 3 files changed, 134 insertions(+)

commit aa97245c713b8cfbcd6216eb6866a46c65f4294e
Author: Balancer <balancer@balancer.ru>
Date:   Tue Sep 23 03:05:23 2014 +0400

    Продолжаем работу с шаблонами.

 classes/bors/layouts/bootstrap3/dropdown.php | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

commit 9baea04d1cb84dc077df2f2918b0bb223f6878f3
Author: Balancer <balancer@balancer.ru>
Date:   Mon Sep 22 08:24:54 2014 +0400

    Bootstrap3 + UIkit, хлебные крошки и таблицы.

 classes/bors/layouts/bootstrap3.php                 | 3 ++-
 classes/bors/layouts/bootstrap3/breadcrumbs.inc.php | 6 ------
 2 files changed, 2 insertions(+), 7 deletions(-)

commit b6f485e1f2e1c673c2007eeae1a125977f1188fb
Author: Balancer <balancer@balancer.ru>
Date:   Mon Sep 22 06:50:52 2014 +0400

    Работающее в первом приближении навигацонное меню в Bootstrap3.

 classes/bors/layouts/bootstrap3.php                |  5 ++
 .../bors/layouts/bootstrap3/breadcrumbs.inc.php    |  6 ++
 classes/bors/layouts/bootstrap3/dropdown.php       | 85 ++++++++++++++++++++++
 3 files changed, 96 insertions(+)

commit 51bac6f052f5ece1d8ed4482b527148e62c1ae75
Author: Balancer <balancer@balancer.ru>
Date:   Tue Mar 18 02:49:00 2014 +0400

    ++

 classes/bootstrap3.php | 5 +++++
 1 file changed, 5 insertions(+)

commit ecef9e2f27862209958bc009ad765e885268e230
Author: Balancer <balancer@balancer.ru>
Date:   Tue Mar 18 02:33:40 2014 +0400

    up

 README.md | 18 ++++--------------
 1 file changed, 4 insertions(+), 14 deletions(-)

commit 6f8c9ad96c2ce55d688d27583974e13db5fe01a8
Author: Balancer <balancer@balancer.ru>
Date:   Tue Mar 18 02:31:45 2014 +0400

    Init

 README.md                                   |  18 +++
 composer.json                               |  37 +++++
 www/css/bootstrap-theme.min.css             |   7 +
 www/css/bootstrap.min.css                   |   7 +
 www/fonts/glyphicons-halflings-regular.eot  | Bin 0 -> 20335 bytes
 www/fonts/glyphicons-halflings-regular.svg  | 229 ++++++++++++++++++++++++++++
 www/fonts/glyphicons-halflings-regular.ttf  | Bin 0 -> 41280 bytes
 www/fonts/glyphicons-halflings-regular.woff | Bin 0 -> 23320 bytes
 www/js/bootstrap.min.js                     |   6 +
 9 files changed, 304 insertions(+)
?

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

Ок. В общем... Рефлоги у тебя были выключены, но в принципе это не проблема, особенно если репозиторий небольшой. Ищем все неиспользуемые коммиты, которые ещё не удалил сборщик мусора:

$ git fsck --dangling
Checking object directories: 100% (256/256), done.
Checking objects: 100% (25/25), done.
dangling commit 573f69d615b6741380eacb373d323a324c1e9bc8
Вот и твой коммит, который ты «удалил» при помощи push --force.

Далее у тебя есть как минимум два варианта:

  • Сделать из него новый бранч:
    $ git branch old-master 573f69d615b6741380eacb373d323a324c1e9bc8
    
  • Сделать этот коммит обратно master'ом:
    $ git update-ref refs/heads/master 573f69d615b6741380eacb373d323a324c1e9bc8
    
Deleted
()
Ответ на: комментарий от Deleted

Ясно, спасибо. Второй вариант всё вернул. Может, в будущем рецепт когда-то и пригодится. Но в своей практике я от Git теперь откажусь. Не для моих рук этот продукт :)

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

Ключ "-f", который затёр историю, можно запретить на стороне сервера, но это больше защита от человеческого фактора. Git - крутая штука и за всё время использования у меня ничего не терялось, хотя репозиториев насоздавал, наверное, уже больше тысячи (включая уже удалённые). Есть удобное git help command и man git command, где всё описано. Для себя наваял короткую справку команд по типичным воркфлоу, вдруг передумаете и Вам пригодится: git-tutorial.

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

hg-git

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

Ёмнип, у этой штуки только один недостаток был, когда последний раз использовал, - no-ff мержи. В остальном, ничего потеряно при её использовании не было.

backbone ★★★★★
()

Кстати, есть у гита еще один косяк: если делаешь hg comm, получаешь коммит со всеми изменениями, кроме новых файлов (их, понятное дело, надо отдельно добавлять). Зато ты можешь ненужные файлы не добавлять, и писать их в .hgignore не нужно, кроме того, hg rm не удаляет файл физически! А в гите нужно (т.к. команды git forget нет, а git rm еще и физически удаляет файл!).

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

// натерпелся этого на нескольких своих велосипедах, которые решил помимо сосфоржа запихнуть на гитхаб — пришлось добавлять еще и git в директорию с проектом

P.S. hg-git я не осилил: у меня портирование упорно отказывалось работать + hg push github по «протоколу» git+https не пахал ни в какую!

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

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

KRoN73 если человек хочет выстрелить себе в голову это его личная проблема и его решение… Но ни одно огнестрельное оружие в мире не будет читать нотации и уговаривать человека не делать это.

Так вот ключик "-f" у git-а в данном случае это равносильно исправному, заряженному пистолету снятому с предохранителя, направленному в голову и в котором уже нажата гашетка. Если ты к тому-же ещё и сам не знал что ты делаешь это не проблема git-а.

Да не вопрос. Просто я на Mercurial привык, что всегда можно откатить ошибочное действие.

До тех пор пока ты принудительно не переписал всю историю в git-е точно так-же можно откатить любое действие.

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

Не читал. Но

P.S. Если опция называется "--force", то перед применением следует читать в документации что именно она делает

this, всё что force, то должно делатся с максимальным вниманием. А так пост похож на anonimous (или как его?), я стал тыкаться наугад, ничего не понял - осуждаю.

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

А я не хочу вникать еще и в VCS! И так дофига времени на мануалы-даташиты уходит!! Я хочу, чтобы VCS просто делала init, commit, diff, push, pull и clone. Больше ничего и не нужно!

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

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

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

Ох, какая насыщенная тема.

Нет (или по крайней мере я не знаю такого простого способа).

Через расширения таки можно.

quantum-troll ★★★★★
()

Да, git push -f может всё похерить. Git дает массу способов выстрелить себе в ногу.

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

Я хочу, чтобы VCS просто делала init, commit, diff, push, pull и clone. Больше ничего и не нужно!

Чтобы работать с VCS надо для начала знать её команды и хоть немного представлять о том что они делают и какие из них могут иметь фатальные последствия. А для этого всего нужно либо самому читать man-ы либо нанять „секретаршу“ которая прочитает man-ы за тебя и в дальнейшем будет исполнять любые твои прихоти по VCS.

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

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

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

Ничего не нужно. Хватит поверхностного представления, т.к. я работаю один, ветки "мержить" мне не надо, так же как и "откатываться", да и вообще никаких веток у меня нет. Мне просто нужно что-то, где я смогу посмотреть разницу между предыдущим коммитом и текущими переделками + хранить свежую версию где-то, не только на дропбоксе!

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

Хочешь я тебе про нуклеосинтез в звездных ядрах расскажу? Намедни как раз минут 15 перед слишком уж любознательными людьми на экскурсии распинался (в ответ на вопрос о солнечных циклах), плавно перешел на сверхновые и если бы народ не слинял, черт-те сколько еще трещал бы ☺

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

:) Да я бы не отказался. Люблю общаться с интересными людьми и специалистами

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

Кстати, есть у гита еще один косяк

Да, это реально неудобно. Но просто неудобства я терпеть готов, а вот столько головной боли (как я понял, единственное, из-за чего я не потерял данные в этой истории — то, что не запускался gc?) на тему сохранности данных — ну его нафиг :-/

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

когда я перехожу с меркуриала (на одной работе) на гит (на другой работе) - как будто глоток свежего воздуха после душного городского смога

У меня в точности, на 100% обратное ощущение. Точнее, когда переходишь с git на mercurial, то до вчерашнего дня было ощущение, что почитав книжку на китайском возвращаешься на русский. А вот теперь ещё и ощущение, что пройдя по минному полю приходишь в уютный дом :D Да, конечно, в доме не получится покататься на тракторе, не принято срать на полу, не вырастить кукурузу... Но и под дождь не попадёшь, и зимой в мороз не замёрзнешь :D

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