Войти
ПрограммированиеФорумОбщее

git clone <URL> <для такой-то даты> (7 стр)

Страницы: 14 5 6 7 8 9 Следующая »
#90
(Правка: 16:50) 16:35, 20 июля 2019

BUzer
> А 3 и 4 обязательно должны быть перед 5-7? Если сначала набить репу коммитами,
> а потом уже делать все эти зеркала, то оно будет работать?
Можно потом (но ваще нада попробовать ))) ). Это я просто повторил свои действия, чтобы наверняка.


#91
16:53, 20 июля 2019

exchg
Всё равно не работает… Точнее, работает не как ожидалось.

Напушил коммитов в bare-репу d:\test_shit\remo, смотрю её рефлог:

PS D:\test_shit\remo> git reflog master --date=iso
6c6aebe (HEAD -> master) master@{2019-07-20 23:37:16 +1000}: push
d1e5167 master@{2019-07-20 23:36:58 +1000}: push
9373a58 master@{2019-07-20 23:36:38 +1000}: push
5daa5eb master@{2019-07-20 20:47:33 +1000}: push
PS D:\test_shit\remo>

Потом проделал все эти операции с bare-mirror и mirror, смотрю рефлог последней:

PS D:\test_shit\mirror> git reflog master --date=iso
6c6aebe (HEAD -> master) master@{2019-07-20 23:42:49 +1000}: push
PS D:\test_shit\mirror>
То есть, только последнее действие, да и то с неправильным временем.

#92
(Правка: 17:58) 17:54, 20 июля 2019

BUzer
> Всё равно не работает… Точнее, работает не как ожидалось.
Не походу оно так работать не будет, я чота погорячился походу или запутался. Нада почитать маны, я навскидку так не могу сказать. По идее в фетч можно просто добавить +logs/*:logs/refs и т.д. но тут вот тот самый вопрос с живыми объектами.

В общем пока можем засчитать половину функционала с рефлогом на ремоте без пула.

#93
5:21, 21 июля 2019

Да вот в инетах че-то пишут, что у гита в протоколе нет вообще ничего, что бы позволило выкачать рефлог.

Но даже если предположить, что мы каким-то образом получили копию ремота с рефлогами и всеми объектами, почему ты думаешь, что это бы не позволило ТС-у сделать аналог того, что он описал вот этом посте: https://gamedev.ru/code/forum/?id=245434&m=5006486#m12 ?

1. Эй, сервер, представь что сейчас 14 ноября 2012-го.
2. git clone <URL>
3. Ок, возвращайся в настоящее.

Мы ведь знаем из рефлога, где были все ветки на этом сервере в указанную дату.

#94
(Правка: 16:39) 16:34, 21 июля 2019

BUzer
> Да вот в инетах че-то пишут, что у гита в протоколе нет вообще ничего, что бы
> позволило выкачать рефлог.
Ну и ты пиши ))) Против лома нет приема. Т.к. по большому счету одно из свойств гита - его структура, а это просто папка с файлами лежащая компактно в одном месте. Всегда можно прийти по той же ssh и забрать либо '.git/logs' либо вообще всю репу. Но это так, в порядке размышлений.

> Но даже если предположить, что мы каким-то образом получили копию ремота с
> рефлогами и всеми объектами, почему ты думаешь, что это бы не позволило ТС-у
> сделать аналог того, что он описал вот этом посте:
Если кратко, то конкретно тут я говорил о том, что без полной истории я не смогу вернутся во времени в четко заданную точку. А без истории локальных ребейзов история получается не полной. И зачем тогда фича которая работает наполовину?

> Мы ведь знаем из рефлога, где были все ветки на этом сервере в указанную дату.
Если в общем - не хочу замыкать круг и отсылать к предыдущим постам. Я уже говорил, что даже если ты сделаешь не просто условную, а отлично работающую машину времени в одном узле, то во первых возникнет вот та самая неопределенность с тем, какой комит из трех взять и положить в рабочее дерево, чтобы сразу компилировать. Да, ты ее предлагаешь решать путем выбора крайнего комита, а я считаю это не верным в рамках гита. Т.к. у нас просто нету понятия сервер в общепринятом для других VCS смысле. У нас есть некий граф, теперь уже не состояний, а узлов которые в случайном порядке обмениваются между собой некими состояниями. И даже больше, несмотря на то, что узлы равноценны нормальным является ситуация, когда совокупность узлов содержит "актуальное состояние" исходных кодов, а не просто каждый индивидуальный узел его дублирует. При этом у нас нету глобального (общего) времени и порядка этого обмена. Сама же система адресует свои состояния через хеши и теги, время внутри нее локально и свободно изменяемо. С такова ракурса вообще непонятно зачем привязаться ко времени.

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

#95
(Правка: 6:01) 5:52, 22 июля 2019

exchg
> полной истории
Это что ещё за фрукт такой? Какая-то новая сущность в нашей дискуссии?

> А без истории локальных ребейзов история получается не полной.
А с историей локальных изменений это получится не то, что требовалось, потому что история сервера станет неконсистентной. К примеру, сегодня я просил состояние на 20 июля 12:00, и сервер мне показал на один коммит, а завтра кто-то закачал туда свою историю работы в этот день, и тот же самый запрос к серверу на 20 июля 12:00 начал возвращать что-то другое. Мы ведь просили сервер представить, что он оказался в прошлом. А в прошлом ему ещё не было ничего известно про то, что кто-то там у себя локально что-то ребейзил, поэтому и выдавать эту информацию будет враньём с его стороны.

> Да, ты ее предлагаешь решать путем выбора крайнего комита, а я считаю это не
> верным в рамках гита.
Ты имеешь ввиду тот случай, когда у нас есть три коммита с одинаковым временем? Ну так давай же спросим у самого гита, что он считает верным!
Вот был у нас такой рефлог:

D:\test_shit\remo>git reflog master --date=iso
6c6aebe (HEAD -> master) master@{2019-07-20 23:37:16 +1000}: push
d1e5167 master@{2019-07-20 23:36:58 +1000}: push
9373a58 master@{2019-07-20 23:36:38 +1000}: push
5daa5eb master@{2019-07-20 20:47:33 +1000}: push

Мы такие пошли в logs\refs\heads и отредактировали файл master, поменяв в нём время первых трёх пушей (5daa5eb, 9373a58, и d1e5167) на одинаковое. Получился такой рефлог:

D:\test_shit\remo>git reflog master --date=iso
6c6aebe (HEAD -> master) master@{2019-07-20 23:37:16 +1000}: push
d1e5167 master@{2019-07-20 20:47:33 +1000}: push
9373a58 master@{2019-07-20 20:47:33 +1000}: push
5daa5eb master@{2019-07-20 20:47:33 +1000}: push

И теперь нам любопытно, какой же ответ даст git, если мы попросим его сказать, где был master в 2019-07-20 20:47:33 ?
Барабанная дробь...

D:\test_shit\remo>git rev-parse master@{2019-07-20.20:47:33}
d1e516774ebf9db25f9b16d7222a5859bc29d278

Кто бы мог подумать, гит разрешил неразрешимую неопределённость, и выбрал крайний коммит! Можешь написать Торвальдсу, что считаешь этот подход не верным :)

#96
(Правка: 6:19) 6:04, 22 июля 2019

BUzer
> Кто бы мог подумать, гит разрешил неразрешимую неопределённость, и выбрал
> крайний коммит!
Вот это поворот!1 А я то думал он выберет первый, ну или средний... Ну теперь подождем пока он выберет актуальный. Ты почитай то о чем речь была.

> Можешь написать Торвальдсу, что считаешь этот подход не верным :)
Я не могу, он гений.

UPD:
> Ты имеешь ввиду тот случай, когда у нас есть три коммита с одинаковым временем?
> Ну так давай же спросим у самого гита, что он считает верным!

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

Повторюсь - все твои рассуждения находятся в парадигме централизованного сервера и "малоправных" клиентов.

#97
7:35, 22 июля 2019

exchg
> Ну теперь подождем пока он выберет актуальный. Ты почитай то о чем речь была.
Сам почитай, в п12 ни слова не было про "актуальный". Там вообще негде нафантазировать неоднозначность.

> после бнального наката бэкапа ремот начнет резко выдавать новую историю
Как и любая другая система (svn и пр.)? Это поведение вполне ожидаемо.

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

#98
(Правка: 7:55) 7:54, 22 июля 2019

BUzer
> Сам почитай, в п12 ни слова не было про "актуальный". Там вообще негде
> нафантазировать неоднозначность.
Почитай о чем была речь речь в моем посте. Тама было сказано, что ровно после того как будет изобретена вот такая фиготень, вдруг окажется, что на самом деле в рабочем дереве не то о чем мечталось.

> Как и любая другая система (svn и пр.)? Это поведение вполне ожидаемо.
Ты мне ща хочешь сказать, что после восстановления репы в TFS или SVN изменяется время? )))  Т.е. комиты за 12 апреля вдруг становятся комитами за 3 ноября? )) После наката бекапа?

> Многие люди работают в гитом в такой парадигме (я бы даже предположил, что
> подавляющее большинство), и это никак не противоречит его распределённой
> натуре.
То, что люди его использует в такой парадигме - не противоречит. То, что люди натягивают ему функционал из этой парадигмы и "кастрирует" его - противоречит. Ты не единственный такой. Например я тут уже вспоминал gvfs.

#99
8:44, 22 июля 2019

exchg
> Почитай о чем была речь речь в моем посте.
Лол, так я тебе задал вопрос по этому посту, который ты проигнорировал: что такое "полная история"? Потому что без определения, я не могу понять, о чём ты в этом посте говоришь, и какое оно имеет отношение к задаче в п12.

> Ты мне ща хочешь сказать, что после восстановления репы в TFS или SVN
> изменяется время? ))) Т.е. комиты за 12 апреля вдруг становятся комитами за 3
> ноября? ))
Подменяешь понятия. Если часть истории в конце тупо пропала — это тоже "выдавать новую историю".
Если кто-то накатит позавчерашний бэкап на сервер, то с него пропадёт информация о коммитах, которые в него сделали вчера, и, соответственно, её не будет в истории. Ты об этом говорил, или какие ещё бэкапы ты имел ввиду?

> "кастрирует" его
У тебя какой-то функционал пропадёт в гите, если добавить ему в протокол возможность скачать рефлог?

#100
9:58, 22 июля 2019

BUzer
> Лол, так я тебе задал вопрос по этому посту, который ты проигнорировал: что
Я не проигнорировал, я уже несколько раз упоминал ее.

> такое "полная история"? Потому что без определения, я не могу понять, о чём ты
> в этом посте говоришь, и какое оно имеет отношение к задаче в п12.
1. Потому, что не читаешь.
2. Потому, что уже несколько параллельных потоков сливаются в один.

Давай обновим:
1. полная история это вся история учетом ребейзов в удаленных репах. Это отвлеченная ветка дискуссии.
2. про задачу в П12 я сказал, что даже если мы ее реализуем и вернемся к нуль-посту, то окажется, что в рабочем дереве лежит не то, о чем мечтали. Потому, что сам по себе не складывает изменения друг на друга и не привязывает их ко времени. Т.е. поход аля SVN будет не верным. В гите, обычно, автор ветки манипулирует сериями комитов и отмечает актуальный тегом ну или мерж комитом с описанием, что случилось. И поэтому у него на указанную дату могут появится три комита. Где гит выберет последний, автор ветки укажет что это средний, а ТСу, может, вообще нужен комит с багом, а он первый. И ему все равно придется выбирать руками и хотелки из нуль-поста не сбудутся.

> Если кто-то накатит позавчерашний бэкап на сервер, то с него пропадёт
> информация о коммитах, которые в него сделали вчера, и, соответственно, её не
> будет в истории.
Чосе, не  мог даже предположить )))

> Ты об этом говорил, или какие ещё бэкапы ты имел ввиду?
Я о том, что если накатят бекап на ремот то пропадет локал-лог со всей историей. И ремот вчера выдававший историю за 12 апреля перестанет это делать.

> У тебя какой-то функционал пропадёт в гите, если добавить ему в протокол
> возможность скачать рефлог?
Понятия не имею. Это же скорее блоатинг.

#101
3:31, 23 июля 2019

exchg
> полная история это вся история учетом ребейзов в удаленных репах. Это
> отвлеченная ветка дискуссии.
А она вообще нужна? Тут, по-моему, никто особо и не выражал хотелку собирать историю со всех удалённых реп в одну.

> про задачу в П12 я сказал, что … хотелки из нуль-поста не сбудутся.
Офигенно, то есть, хотелки из п12 всё-таки сбудутся. Уже что-то :)

> Потому, что [гит] сам по себе не складывает изменения друг на друга и не привязывает
> их ко времени.
Неправда, он в рефлоге делает именно это.

> И ему все равно придется выбирать руками
Ну и пускай выбирает. Как бы тот момент, что не все коммиты будут принципиально достижимы при адресации по времени из рефлогов — это нормально. Ты запушил три коммита одним пушем, в рефлог легла ссылка только на последний. Предыдущие два только лишь при помощи времени ты никак не вытащишь, это by design.

> Я о том, что если накатят бекап на ремот то пропадет локал-лог со всей историей.
Чёт я запутался, локал-лог пропадёт у кого, у ремоута, или у тех, кто к нему за этой историей стучится?

#102
(Правка: 3:52) 3:50, 23 июля 2019

BUzer
> А она вообще нужна? Тут, по-моему, никто особо и не выражал хотелку собирать
> историю со всех удалённых реп в одну.
Было обсуждение параллельно, на тему как и зачем видеть историю ребейзов.

> Офигенно, то есть, хотелки из п12 всё-таки сбудутся. Уже что-то :)
Я не понимаю, о чем ты вообще спорил 7 страниц, если для тебя удивительным открытием являются цитаты из постов первой и второй страницы?

> Неправда, он в рефлоге делает именно это.
Правда. Рефлог не является частью истории.

> Ну и пускай выбирает. Как бы тот момент, что не все коммиты будут принципиально
> достижимы при адресации по времени из рефлогов — это нормально. Ты запушил три
> коммита одним пушем, в рефлог легла ссылка только на последний. Предыдущие два
> только лишь при помощи времени ты никак не вытащишь, это by design.
Офигеть да, ТС говорит, что ему в дереве нужны сразу файлы для компиляции, я ему говорю, что таков может не быть т.к. {тут опять история про три комита} и ему придется в общем все равно руками лазить. Дж если вдруг будет машина времени. Т.е. городить ее просто нету смысла. Потом ты мне 7 страниц чота втираешь, чтобы потом рассказать, что так как я говорил в самом начале это by design ? )))) Я вообще перестал понимать что происходит.

> Чёт я запутался, локал-лог пропадёт у кого, у ремоута, или у тех, кто к нему за
> этой историей стучится?
У ремота. Ты его уничтожишь выкатив бекап. Т.к. рефлог локален, то вся история отраженная в комитах останется на месте, а рефлог нет. И все запросы на которые тебе отвечали вчера будут уже другими.

#103
(Правка: 5:49) 5:45, 23 июля 2019

exchg
> если для тебя удивительным открытием являются цитаты из постов первой и второй
> страницы?
Это для тебя они, видимо, являются удивительным открытием. Ты же утверждал, что "это" не сделает то, что хочет ТС; но вот внезапно оказалось, что таки сделает (как минимум, согласно тому посту).

> Рефлог не является частью истории.
Окей, я объявляю его частью истории :)

> Потом ты мне 7 страниц чота втираешь, чтобы потом рассказать, что так как я
> говорил в самом начале это by design ? ))))
Ну если в жизни ремота никогда не было момента времени, когда голова ветки находилась бы на любом из этих двух коммитов (т.е. когда бы ты мог сделать с него clone и получить их в виде текущего состояния), то логично, что и в истории их тоже нет. В этом же и суть "машины времени". Странно, что это было не очевидно :)

Вообще, я думал, ты про другое говорил. У нас ещё может быть ситуация, когда нам за одну секунду сделали три пуша, они все легли в рефлог, но мы не можем вытащить по времени предыдущие два — просто потому, что разрешения рефлога не хватает, чтобы указать точное время. Гит в этом случае вернёт крайний (что я демонстрировал выше редактированием рефлога). С этим можно жить по разному: либо просто забить, либо увеличить разрешение до каких-нибудь микросекунд (как в SVN) и забить, либо увеличить разрешение и запретить делать пуши чаще, чем позволяет разрешение лога и системного таймера.

> У ремота. Ты его уничтожишь выкатив бекап. Т.к. рефлог локален, то вся история
> отраженная в комитах останется на месте, а рефлог нет.
Я может не совсем понимаю, но почему бэкап уничтожает историю, но не уничтожает коммиты? Потому что коммиты останутся у клонов? Ну так история тоже останется у клонов.

#104
(Правка: 16:36) 16:04, 23 июля 2019

BUzer
> Это для тебя они, видимо, являются удивительным открытием.
Мои же утверждения? Свежо. ))))

> "это" не сделает то, что хочет ТС; но вот внезапно оказалось, что таки сделает
Нет не сделает, почему я писал на первой странице, на второй, и персонально тебе несколько раз задавал вапрос - допустим машина времени есть, и она выдает три комита и далее по кругу.

"Это" сразу не положит в рабочее дерева ТСу, то что он считает актуальным и можно будет сразу компилировать. И именно  поэтому ниже ты предлагаешь очередное убер решение которое самими свои существованием показывает, что таки не сделает.

> Окей, я объявляю его частью истории :)
Мелко, объявляй, что можно качать и мержить реф лог.
UPD: нет, это тоже мелко, объявляй что решением будет команда - git dwim )))

> Вообще, я думал, ты про другое говорил.
> У нас ещё может быть ситуация, когда нам за одну секунду сделали три пуша,
Я за это тоже говорил.

> С этим можно жить по разному: либо просто забить
ТСу нельзя. Еу нужно сразу и не лазить руками.

> увеличить разрешение до каких-нибудь микросекунд (как в SVN) и забить, либо
> увеличить разрешение и запретить делать пуши чаще, чем позволяет разрешение
> лога и системного таймера.
Я знаю решение проще. Разделить клиент и сервер и все операции проводить на сервере, тогда будет очередность + единое время и можно скачать в любой момент полную историю. Шах и мат ))) Ну т.е. мы возьмем гит потому что это модно, и сделаем из него svn/tfs потому что мы по другому не умеем. Вот в сотый раз читая подобный бред задаю себе вопрос - зачем эти люди используют гит?

Еще раз в гите история это узел графа которой просто имеет свое место (родиетя). Все остальное - второстепенно. И время и имя а даже комит месседж, и даже представление адреса.

> Я может не совсем понимаю, но почему бэкап уничтожает историю,
Потому, что у тебя две страницы назад не получилось заливать в бекап рефлог?

> Потому что коммиты останутся у клонов?
Потому, что смысл бекапа - сохранять историю изменений. Рефлог в нее не входит, даже если ты это объявил. 

> Ну так история тоже останется у клонов.
У клонов остается персональный рефлог. Чтобы из этого что-то сделать их все нужно собрать в одном месте и смержить.

Страницы: 14 5 6 7 8 9 Следующая »
ПрограммированиеФорумОбщее