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

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

Страницы: 1 2 3 4 Следующая »
#15
(Правка: 19:36) 19:35, 7 июля 2019

DEN
> Неумение пользоваться гитом == неумение программировать, я правильно понял? :)
Я говорю о том, что или он описывает все свои странности в ридми или никто не ходит в его репозиторий. Причем тут умение программировать?

> Та хоспаде, речь просто о том, чтобы взять машину времени, отправиться в
> прошлое, и сделать там git clone.
Я понимаю. Но такова нету.  Нету не просто машины времени. Нету самого понятия "сорцы из репозитория, актуальные на такой-то момент времени" Для того чтобы оно появилось необходимо организовать репозиторий соответствующим образом.

Кстати вопрос - ну вот допустим есть машина времени. Ты клонировал. Дальше что?  Ведь для того, чтобы перейти к твоему пункту Скомпилить сорцы ты должен выбрать нужное тебе состояние. И в чем теперь разница (кроме трафика) в твоих действиях при полном и частичном клонировании?

> Это вообще можно сделать на уровне HTTP-кеширования не трогая гит
> (теоретически, теоретически, спокойствие).
Нет нельзя, даже теоритически. Т.к. http это всего лишь один из протоколов который используется гитом.

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


#16
(Правка: 20:32) 20:31, 7 июля 2019

exchg
> Нету самого понятия "сорцы из репозитория, актуальные на такой-то момент времени" Для того чтобы оно появилось необходимо организовать репозиторий соответствующим образом.
> Нет нельзя, даже теоритически.
Хорошо, объясню еще подробнее. Репозиторий гита - это хранилище данных. Запросы к этому хранилищу можно разделить на две группы: read-only, и которые вносят какие-то изменения. Не важно какие: добавляем мы что-то новое, удаляем старое, меняем существующее, отбранчевываемся, или мержимся с существующим бранчем. В этом смысле не важно, гит это, база данных на клиппере, или мозг робота Алёши. Каждое внесение изменений происходит в некоторый физический момент времени. Имея множество всех пар <момент времени; вносимые изменения> можно восстановить состояние репозитория в любой момент времени. Можно по-быстрому наговнокодить строк в 50 на php следующую предбанник-прослойку: смотрим, какой пришел запрос. Если read-only - то просто форвардим его на гит. Если вносятся какие-то изменения, то форвардим запрос на гит, после чего делаем git clone <url>, mv reponame <timestamp>. Плюс добавляем команду git den-clone <url> <date>, которая вместо похода в репозиторий выдает наиболее подходящую копию репы. Это в лоб и тупо, но думаю идея ясна. Функциональность самого гита от этого никак не пострадает.

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

#17
(Правка: 21:03) 21:01, 7 июля 2019

DEN
> Хорошо, объясню еще подробнее.
Да ты прочитай вначале. HTTP это один из нескольких протоколов, еще есть  как минимум ssh и file.

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

> По сути это просто архивирование репы после каждого изменения и запрос "слепка"
> из архива.
Вопрос в том зачем это нужно? Какую проблему это решает? Ты просто раздуваешь размер хранимых данных. Напомню, что репы бывают и по несколько гигабайт, а бывает и несколько сотен. Через сколько дней у тебя закончится место?

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

#18
23:16, 7 июля 2019

DEN
Зачем работать с гитом как с базой данных?

#19
(Правка: 9 июля 2019, 3:36) 4:28, 8 июля 2019

Dan Diamond
> Зачем работать с гитом как с базой данных?
ну потому что с svn-ом получалось с полпинка, то и к гиту запросы соответствующие...

svn export -r {дата}
как вариант-  поставить какой-нить svn over git и делать бекапы сборку git репозитории через svn :)
#20
(Правка: 7:38) 7:36, 8 июля 2019

DEN
> Репозиторий гита - это хранилище данных. Запросы к этому хранилищу можно
> разделить на две группы: read-only, и которые вносят какие-то изменения.

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

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

Представь, проект начался 1 числа, шел линейно, 8 числа Иванов и Петров склонировали репозиторий каждый к себе и начали реализовывать какие-то свои фичи, а 15 числа смерджилились, каждый сделав на своем пути по 3-4 коммита. У тебя в репозитории одна ветка - мастер, но до 15 числа граф имеет два разных пути. Понятно, что коммиты из этих путей нельзя рассматривать как линейную историю - 13 числа Иванов сделал у себя коммит, добавив фичу И3 к реализованным за это время фичам И1 и И2, а 14 числа - Петров сделал у себя коммит, добавив фичу П4 к реализованным за это время фичам П1, П2 и П3.

Если брать коммиты последовательно по времени, то при переходе с ивановского коммита 13 числа на петровский коммит 14 числа у тебя "разом исчезнут" все фичи И1, И2 и И3, и сразу же появятся все фичи П1, П2, П3 и П4 - понятно же, что таких изменений с "убиранием нескольких фич и одновременным добавлением нескольких других" никто в проект никогда не вносил.

#21
(Правка: 9:40) 9:38, 8 июля 2019

DEN
> Та хоспаде, речь просто о том, чтобы взять машину времени, отправиться в
> прошлое, и сделать там git clone
Тебе подойдёт любой из 29 коммитов, сделанных 23 апреля 2019? Или самый последний? Но самый последний не будет собираться, потому что к нему прилетел фикс в 00.01 24 апреля.

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

git clone URL
git checkout `git rev-list -n 1 --before="2009-07-27 13:37" master`

А вообще, если надо организовать совместное использование нескольких реп, то лучше всего использовать подмодули.

#22
(Правка: 14:31) 13:26, 8 июля 2019

DEN
Нет понятия "на конкретную дату", это бред собачий. Во первых в одну дату может быть несколько коммитов, есть разные часовые пояса, а самое главное, коммит который был сделан 10 числа может быть родителем коммита, который был сделан 9-го.

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

Ты какую проблему то хочешь решить? Если у тебя ограничение по трафику или месту на диске, ставь depth --1 и выкачивай нужный коммит с нужным хешем.  Ты начинаешь придумывать какую-то херню, которая никому кроме тебя не нужна.

#23
17:27, 8 июля 2019

9К720
Для этого существует стандартизация. Условиться что время без таймзоны по utc, если несколько коммитов брать самый поздний.
Хотя идея странная конечно, согласен

#24
3:01, 9 июля 2019

> система контроля версий
> не может вычислить состояние проекта на определённую дату

Ай Торвальдс, ай маладца.

#25
(Правка: 11:07) 11:03, 9 июля 2019

BUzer
> Ай Торвальдс, ай маладца.

Для работы с git разработчику необходимо научиться работать с направленным ациклическим графом (DAG, Directed Acyclic Graph), что уже непросто, а тут мы просим его работать с несколькими слабосвязанными направленными ациклическими графами одновременно и к тому же следить за порядком выполнения checkout/commit/push в них. Это уже слишком.

"Авторитеты" говорят, что git это для осиливших сложнейшее понятие - дерево.
#26
12:26, 9 июля 2019

exchg
При чём тут дерево? Проблема с откатом на нужную дату — она больше в плоскости механизма GC и отсутствия истории изменения "указателей" веток.

#27
17:32, 9 июля 2019

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

> Проблема с откатом на нужную дату
Проблемы вообще нету. Несколько человек уже упомянули, что у гита нету понятий - "нужная дата", "актуальное состояние". Соответственно ты не можешь туда перейти байдизайн. И его нету не потому, что это сложно или торвальдс дурак. Если тебе такое надо - иди в svn, tfs и прочие системы которые оперируют наборами изменений привязанными к дате. Зачем себя превозмогать.

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

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

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

#28
2:12, 12 июля 2019

exchg
> свободно меняющих местоположение
Не надо вводить народ в заблуждение, никто там никуда местоположение не меняет. Единственное, что может сделать узел в этом графе — это сдохнуть, если его гц прибьёт.

> человек не сможет задавать вопрос - а почему
> нету актуального состояния за день Х.
Ну так я и не задаю :)

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

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

> В общем это дело упростит код, потому что просто придется выкинуть гитовый GC и
> обозвать это фичей.
Да, можно было бы заодно выкинуть рефлог, а также ссылки сабмодулей перестали бы протухать после всяких ребейзов. Может быть даже форс-пуши не были бы такой проблемой для остальных, кто что-то делал в этом же бранче, т.к. у клиента было бы больше возможностей просчитать изменение без конфликта.
Насчёт раздувания размера репы, ну тут хз, по идее ребейз в чистом виде не должен особо ничего сожрать, т.к. файлы в репе хранятся по ссылкам, и они до/после ребейза по большей части одни и те же.

> Если тебе такое надо - иди в svn, tfs и прочие системы которые оперируют
> наборами изменений привязанными к дате. Зачем себя превозмогать.
Ну это же не текстовый редактор или браузер, где ты просто юзаешь что больше нравится. Тут надо, чтобы вся команда в одной системе сидела.

#29
(Правка: 1:32) 0:07, 13 июля 2019

BUzer
> Ну так я и не задаю :)
А я и не про тебя говорю ))

> Не надо вводить народ в заблуждение, никто там никуда местоположение не меняет.
Ага, а ребейз это что по твоему? ))) Как раз он и меняет "положение", и народ это не понимает и оттого фантазирует на тему истории связанно с датами.

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

> А какую проблему должен был решить рефлог?
А какую проблему вообще решает лог? Для начала он отображает действия которые были применены к тому или иному объекту. И косвенно служит для восстановления случайно погибшего. Кстати сам по себе реф лог дфет только имя.

> и что откатывать состояние "ненужно и нереализуемо", то откуда тогда взялся
> этот костыль, который хранит весь твой мусор три месяца, не давая GC его
> собрать?
А откуда взялся костыль который позволяет восстановить удаленный файл в ФС ? Говорят в основном о том, что оно бессмысленно и дорого и самое главное никак не решает проблему ТСа. Тем более, что для бекапов файлов нет проблем и есть куча тулов настраивай любой и пользуй при необходимости. А во вторых еще раз напоминаю, что гит это децентрализованная система, там не выйдет просто откатить мастера и синкнуть рабов.

Кста для справедливости если я ничего не путаю, то рефлог не восстанавливает состояние в вашем с ТС понимаинии. Он просто позволяет получить имена отцепленных от головы/тега, но живых еще живых цепочек коммитов.

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

> Наверное потому что даже у Торвальдса бывают случаи, когда он факапит свой
> любимый граф, и ему надо вернуть профуканное состояние
Конечно бывает. Торвальд обычный человек. Зачем в него постоянно тыкать пальцем непонятно.

> Почему? Если бы была история изменения "указателей" веток, то нам было бы
> плевать на время, записанное в коммите — мы бы брали его из истории указателей.
Потому что у тебя за определенно число будет более одного состояния. И нету никакого способа понять какое из них актуально, а какое нет (читай внимательно пункт 2 требования ТСа). Только программист может достоверно определить это. Кроме того, делая (например) ребейз ты можешь засунуть сегодняшний комит во вчера. И тут уже непонятно, считать это уже сегодняшней историей или править вчерашнюю? 

> Да, можно было бы заодно выкинуть рефлог, а также ссылки сабмодулей перестали
> бы протухать после всяких ребейзов. Может быть даже форс-пуши не были бы такой
> проблемой для остальных, кто что-то делал в этом же бранче, т.к. у клиента было
> бы больше возможностей просчитать изменение без конфликта.
Я не понимаю как эти страдания связанны с темой.
1. Реф лог это же и есть история изменения указателей веток, не?
2. по ссылкам сабмодулей непонятно как это поможет, для меня это вообще странная история.
3. для форспуша все будет аналогично как и сечас. Я скачал историю, и на основе нее строю свою ветку, а кто-то пушит откат истории на день назад.  В итоге у меня ветка опирается на то, чего уже нету. В чем же разница? И главный вопрос - на основании чего делать предположения о том как разруливать данную ситуацию. 
4. про конфликты сложно сказать навскидку. Лучшая стратегия, как по мне, это заставить разбираться человека. ему виднее. Не зря даже re-re-re по дефолту отключен.

> Насчёт раздувания размера репы, ну тут хз, по идее ребейз в чистом виде не
> должен особо ничего сожрать, т.к. файлы в репе хранятся по ссылкам, и они
> до/после ребейза по большей части одни и те же.
Ты же вот только что писал  про GC который убивает объекты!!!  Как ты будешь откатывать историю если у тебя умерли объекты? Кроме ребейза есть временные ветки которые просто умирают т.к. больше не нужно. И вот я вчера убил две ветки, а сегодня хочу откатить на вчера. Где мои веточки?

> Ну это же не текстовый редактор или браузер, где ты просто юзаешь что больше
> нравится. Тут надо, чтобы вся команда в одной системе сидела.
Да. И раз уж ты согласился пользоваться/тебя заставили, то нужно пользоваться руководствуясь в первую очередь инструкцией от создателей. Для этого нужно с ней ознакомиться, понять как работает, какие принципы заложены, какие варианты получили распространение и почему и из этого всего уже исходить.

Страницы: 1 2 3 4 Следующая »
ПрограммированиеФорумОбщее