Я снес свой проект к ебб

двух недельного кода, а так же гит

2 недели никуда не закоммиченного? Зря.

Помню у меня было похожее, но удалились только py файлы (опечатка была, вместо pyc было py), pyc остались, но погуглив оказалось что проще все переписать чем пытатся их декодировать :D

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

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

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

Процитирую kegdan:

Погоди, я сейчас разлогинюсь и стану таким же офигенным, как ты

make clean нынче не модно, пацаны делают find -delete ?

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

буду показывать твой топик падаванам со словами «почему надо учить git до того как учиться говнокодить на php и python»

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

Обычно такой опыт дается гораздо дороже...

это же не какой-то сраный svn, где постоянно нужно делать svn ci. В git же локальный репозиторий и все дела, пальцы в перстнях, тёмные очки.

...и внезапная безысходность.

Слава svn, короче! Я знал.

TS, ты что-нибудь спас?

ТС походу вбросил и собрал мешок лулзов и от обжорства умер.

Шёл 2014 год. битовоеведёрко и его приватные репо/github для раков dropbox/google-disk/yandex-disk и т.д. НУ КАК!? НУ КАК ВЫ ТЕРЯЕТЕ КОД!?

Блин, надо сделать бэкапы.

Резервирование...
Синхронизация...

М-да, вот что бывает со школотой (которая, порой, даже ученую степень может иметь) на фоне отсутствия азов культуры разработки. Показательная тема.

В б-мерзкой вендовой консоли (powershell), к слову, есть режим what-if - когда выполнеие команды или скрипта ничего физически не делает, а лишь показывает, что случится, если скрипт запустить «нормально».

Ты их вручную делаешь?!? Да, билетов в цирк не надо, когда ЛОР есть!

Да, по напоминанию ЛОРа. Даже крон не нужен.

«бэкап средствами VCS» — это ветка-WIP, в которой относительно твоей topic branch всегда один коммит.
Этакий stash вручную, который можно запушить на удалённый сервер. Считаешь, это плохо?

Я считаю, что это в лучшем случае бесполезно. «stash вручную на сервере» не дает ничего по сравнению с rsync на сетевую шару (на самом деле, rsync восстановит полное состояние рабочего каталога - в отличие от clone с сервера). А как «stash вручную на сервере» взаимодействует с CI и прочей автоматизацией?

Я реально так работаю, да.

Люди вообще делают много странных вещей. Тема выгоды по сравнению с копированием на сетевую шару не раскрыта.

clone с сервера и последующий git reset HEAD~ тоже восстановит состояние каталога.

С continuous integration дела не имел, но почему ещё одна ветка на сервере должен как-то с ней взаимодействовать?

Тема выгоды по сравнению с копированием на сетевую шару не раскрыта.

Эффективнее (delta transfers, все дела). Ну и, собственно, не нужно отдельно настраивать сетевую шару. Достаточно уже имеющегося гитхаба/приватного Git-сервера.

clone с сервера и последующий git reset HEAD~ тоже восстановит состояние каталога.

Нет. Всяческие сгенерированные файлы не восстановятся.

С continuous integration дела не имел, но почему ещё одна ветка на сервере должен как-то с ней взаимодействовать?

Не обязана. У тебя на сервере будет 2 ветки - одна для бэкапа, с которой CI и люди не взаимодействуют, другая для предоставления кода на тестирование и ревью. И ради чего всё это, напомни?

Тема выгоды по сравнению с копированием на сетевую шару не раскрыта.

Эффективнее (delta transfers, все дела).

Я специально написал rsync.

Ну и, собственно, не нужно отдельно настраивать сетевую шару. Достаточно уже имеющегося гитхаба/приватного Git-сервера.

Если ты гусар-одиночка, то копируй просто в другой каталог. От факапов вроде описанного это тебя спасет (не хуже «приватного git-сервера»).

сгенерированные файлы не восстановятся.

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

Не обязана.

О чём и речь.

Я специально написал rsync.

Git эффективнее, чем rsync. Причина: на клиенте есть и старое состояние, и новое. Между ними можно сделать delta compression.

копируй просто в другой каталог.

Это-то тут при чём? И да, от крэша ФС не спасёт, от утери рабочей машины не спасёт, от rm -rf $HOME /junk — тоже.

В любом случае, чем меньше инфраструктуры, тем лучше.

сгенерированные файлы не восстановятся.

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

То есть ты не возражаешь против того, чтобы переконфигурировать и пересобрать потенциально большой проект. Окей.

О чём и речь.

Речь о другом, но ты предпочел этого не заметить.

Git эффективнее, чем rsync. Причина: на клиенте есть и старое состояние, и новое.

Почитай, как работает rsync. Git, может быть, и эффективнее «в общем», но не думаю, что он измеримо эффективнее в твоем конкретном случае.

копируй просто в другой каталог.

Это-то тут при чём? И да, от крэша ФС не спасёт, от утери рабочей машины не спасёт, от rm -rf $HOME /junk — тоже.

Я написал, причем это и от чего это спасет.

В любом случае, чем меньше инфраструктуры, тем лучше.

Ты мог бы сразу написать «я гусар-одиночка и мне удобно использовать github как offsite backup».

То есть ты не возражаешь против того, чтобы переконфигурировать и пересобрать потенциально большой проект. Окей.

Вообще не возражаю. На то мне и Хасвелл четырёхглавый в качестве центрального процессора. Вообще, в случае backup restore event время, затраченное на переконфигурировать+пересобрать, будет невелико в сравнении с временем, затраченным на восстановление всего остального.

Речь о другом, но ты предпочел этого не заметить.

Ась? Ты спросил, «как взаимодействует», наверняка подразумевая под этим «не поимеет ли». Ответ — нет, всё норм, не поимеет, вместо N веток будет N+1.

Я написал, причем это и от чего это спасет.

Но исходно-то было обсуждение (сравнение) совершенно других методов бэкапа, и «копирование в соседнюю директорию» по сравнению с ними одновременно неэффективно и бесполезно.

Ты мог бы сразу написать «я гусар-одиночка и мне удобно использовать github как offsite backup».

Это, безусловно, так. Но разве в каком-то другом случае написанное мною неверно?

То есть ты не возражаешь против того, чтобы переконфигурировать и пересобрать потенциально большой проект. Окей.

Вообще не возражаю. На то мне и Хасвелл четырёхглавый в качестве центрального процессора

Тогда странно, что ты задумываешься об эффективности rsync по сравнению с git. И кстати, переконфигурирование подразумевает некоторое количество ручной работы, от которой Хасвеллы не помогают.

Вообще, в случае backup restore event время, затраченное на переконфигурировать+пересобрать, будет невелико в сравнении с временем, затраченным на восстановление всего остального.

Да? А я думаю, что для описанного в хедпосте сценария «restore event» может состоять из одной команды rsync.

вместо N веток будет N+1.

Вместо N веток будет 2N. Или ты все незаконченные работы будешь бэкапить в одну ветку?

разве в каком-то другом случае написанное мною неверно?

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

Тогда странно, что ты задумываешься об эффективности rsync по сравнению с git.

На вычислительные затраты мне класть, в отличие от wall time, пропускной способности сети и затрат места на дисках.

Да? А я думаю, что для описанного в хедпосте сценария «restore event» может состоять из одной команды rsync.

Действительно, с этой стороны твоё решение лучше.

Насчёт переконфигурирования — возможно, ты прав. Впрочем, моя модель управления данными представляет собой 1) сравнительно редкий бэкап всей машины и 2) частый бэкап того, над чем работаю. В этой ситуации конфиг можно будет найти в общесистемном бэкапе (он меняется не слишком часто).

Вообще, идея в том, что сильно влом где-то поднимать инфраструктуру для rsync'а или сравнимых средств пофайлового бэкапа, которые предполагается запускать очень часто. А репозиторий уже есть.

На вычислительные затраты мне класть

Тебе и на более важные вещи класть.

Лучше пересмотри джонни мнемоника!

okay.jpg

Спешите видеть: tailgunner плодит сущности.

Зачем мне строить систему резервирвоания/версионирования кода из rsync и костылей, если git может решать ровно эту же задачу, и git-сервер УЖЕ РАБОТАЕТ? Может быть, если у вас уже была инфраструктура со времён использования svn, когда работа с системой хранений версий была через задницу, это имеет смысл. А костылять с нуля — не имеет.

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

Для нетривиальных сборочных скриптов заводится свой репозиторий. Делаешь на сервере репу ~юзернейм/мои-билдскрипты-нашего-суперпуперпроекта, и коммитишь туда всё, что сложнее, чем ./configure --prefix=$HOME/build.

Как результат,

• конфигурация твоей сборки может быть развёрнута на любой машине одной командой;
• если реп публичный, Вася Пупкин всегда может воспользоваться твоим опытом (или ты можешь воспользоваться его опытом);
• всегда можно найти ответ на вопрос «Как я собирал эту херню 2 недели назад, и почему сейчас у меня валится сборка точно той же ревизии? ЧЯДНТ?»

А если для сборки приходится делать что-то совсем уж нетривиальное, надо бы задуматься, что, что-то не так в консерватории, и внести изменения в сборочный процесс. И ссылка на репу — отличный способ продемонстрировать проблему человеку, который отвечает за сборочные процедуры в проекте. (Вместо того, чтобы простыни sh-кода аттачить к сообщениям в баг-трекере.)

Спешите видеть: tailgunner плодит сущности.

rsync для бэкапа - лишняя сущность? Где вас таких находят.

rsync для бэкапа - лишняя сущность?

Вот git-сервер rsync-ом и бэкапь. Для rsync бэкапа рабочей копии — лишняя сущность.

Где вас таких находят.

А вас?

git-сервер rsync-ом и бэкапь

Зачем? Совершенно очевидно, что бэкапить git-сервер нужно пушем в другой git-сервер.

Для rsync бэкапа рабочей копии — лишняя сущность.

Если каждый день делается обычный рутинный бэкап - да. Но ТС его не делал.

Зачем? Совершенно очевидно, что бэкапить git-сервер нужно пушем в другой git-сервер.

Совершенно очевидно, что один «скучный инженер» не умеет в абстракции. git решает задачи ведения проекта. Бэкап содержимого накопителей сервера решает задачи устойчивость к сбоям. Ты же мешаешь всё в кучу.

Если рабочая копия сорцов не содержит ничего ценного, её незачем бэкапить. А если содержит, то её место — в отдельном бранче репозитория, а не в очереди на бэкап rsync-ом.

Если каждый день делается обычный рутинный бэкап - да. Но ТС его не делал.

Если у ТСа личный комп с уникальными данными, и он не делает бэкапы — он ССЗБ. Если же у него просто рабочее место, а хранение данных организовано на другой машине, то он тоже ССЗБ, потому что 2 недени не пушил рабочую копию.

Это неинтересно -мы простые скучные инженеры.

Видимо, вам ОЧЕНЬ скучно, раз вы маетесь плождением сущностей.

git решает задачи ведения проекта. Бэкап содержимого накопителей сервера решает задачи устойчивость к сбоям. Ты же мешаешь всё в кучу.

Это не я предлагаю использовать git-сервер как хранилище бэкапов. Какой смысл с тобой спорить, если ты не понимаешь написанного текста? Успехов.

Это не я предлагаю использовать git-сервер как хранилище бэкапов.

Ваще-то как раз ты не понимаешь концепцию «пушить каждое изменение», воспринимая её как «бэкап через VCS», чем она не является. Твои слова:

То, что последовательность коммитов должна как-то отражать выполняемое задание, ты, похоже, не думаешь. Ты реально так работаешь или в просто хочешь победить в споре о том, что VCS - это инструмент бэкапа?

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

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

Ваще-то как раз ты не понимаешь концепцию «пушить каждое изменение»

Эта концепция - странное говно.

воспринимая её как «бэкап через VCS», чем она не является

Осваивай трудную науку чтения и понимания текста. Тебе будет трудно, но я верю в тебя.

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

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

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

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

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

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

Всем спасибо, за советы, дискуссию, testdisk и ext4magic действительно отличные инструменты, часть кода восстановил, часть переписал, один совет тем кто случайно оказался в подобной ситуации, когда ты понял, что безвозвратно все снес и твое лицо побелело, нужно собраться и сразу же либо отмонтировать раздел с которого был удален контент, либо вырубать девайс (ноут, комп). Уже третий день пушу на сервак все изменения в отдельную ветку гит... Еще раз всем спасибо.

Зачем пушить не готовый код?

Пуш его в ветку. На то и придумано.