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

git clone <URL> <для такой-то даты>

Страницы: 1 2 38 9 Следующая »
#0
(Правка: 22:11) 22:10, 6 июля 2019

Привет. Существует ли способ склонировать репозиторий в том виде, в котором он был в заданную дату? Гуглеж по теме показывает ряд различных решений и кучу обсуждений этих решений. Так обычно бывает, когда задача решается исключительно через задницу. Во-первых - я боюсь что-нибудь испортить. Во-вторых - нагугленное у меня не работает. В третьих - мне не нужно делать это в рабочей папке. Мне нужно: 1) Склонировать в пустую папку сорцы из репозитория, актуальные на такой-то момент времени, 2) Скомпилить сорцы, 3) Удалить сорцы. ВСЁ! Я-то по наивности ожидал, что у команды git clone <URL> будет дополнительный параметр типа date=..., но вместо этого я вижу в гугле только какие-то ритуалы по вызову диавола. Наверно парни в свитерах с оленями сделали это по какой-то весомой причине, типа секурити или вроде того, но это все мне не надо - мне надо просто забрать сорцы на момент заданной даты, и все. Заранее спасибо :3


#1
22:23, 6 июля 2019

Git работает не с датами, а с коммитами.
Клонируй как есть, потом делай чекаут на коммит, предшествующий интересующей тебя дате.
Историю коммитов можешь посмотреть через git log.
Потом делай
git checkout хэш_интересующего_коммита -b название_новой_ветки

#2
22:28, 6 июля 2019

Dmitry_Milk
> потом делай чекаут на коммит, предшествующий интересующей тебя дате.
> Потом делай git checkout...
Это два разных действия, или ты дважды описал одно и то же? Я просто не силен в латыни :) Хеш я могу посмотреть на битбакете.

> название_новой_ветки
Что такое новая ветка и откуда взять ее название?

#3
22:28, 6 июля 2019

git clone <repo_url>
git log --after="yyyy-mm-dd 00:00" --before="yyyy-mm-dd 23:59"
—тут список коммитов за указанный промежуток времени
git checkout <commit_hash>

#4
23:28, 6 июля 2019

Dan Diamond
Спасибо, кажись получилось.

Изображение
#5
0:13, 7 июля 2019

DEN
> You are in 'detached HEAD' state

Если б вместо
git checkout <commit_hash>
сделал
git checkout <commit_hash> -b <название_ветки>
, то не было бы 'detached HEAD' state. Название - какое выберешь сам.

#6
3:26, 7 июля 2019

Dmitry_Milk
> Git работает не с датами, а с коммитами.
Если я правильно понял как работает git, дело прежде всего в том, что clone забирает не какую-то определенную версию, а весь репозиторий целиком, со всей историей изменений. И далее уже переход в нужное место делается локально. Правильно?

#7
8:21, 7 июля 2019

DEN
Верно

#8
13:04, 7 июля 2019

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

#9
14:02, 7 июля 2019

DEN
Можно теги для релизов использовать. Выкатили релиз, пометили тегом версию релиза, на клиентской машине забрали, вычекнули коммит с тегом последнего релиза, собрали.

#10
(Правка: 14:31) 14:02, 7 июля 2019

DEN
> Если я правильно понял как работает git, дело прежде всего в том, что clone
> забирает не какую-то определенную версию, а весь репозиторий целиком, со всей
> историей изменений. И далее уже переход в нужное место делается локально.
> Правильно?
Нет. Гит забирает столько, сколько ты его попросишь забрать. Минимум - один коммит, максимум - все. По умолчанию клонируется весь репозиторий.

> Что же касается забора по дате - если конечных продукт собирается из нескольких
> репозиториев, то возня с хешами коммитов выглядит не слишком удобной, забор по
> дате был бы куда лучше.
Чтобы не возится с хешами коммитов есть теги и ветки. Скажем у тебя за 1 апреля есть 124 коммита. Ну вот забрал ты все 124 коммита по дате, дальше что?

Кроме того, дата создания коммита никак не связана с его положением в истории. Например коммиты за 5 апреля могут стоять перед/раньше коммитов за 1 апреля.

#11
16:20, 7 июля 2019

DEN
> забор по дате был бы куда лучше
Не по дате, а HEAD ветки, если контент изменяющийся, или tag, если контент неизменный - это именно те механизмы, которые предназначены для решения тех задач, которые описаны в первом посте.
Историю выкачивать не обязательно, достаточно поставить --depth 1

#12
17:05, 7 июля 2019

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

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

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

Но как я уже понял, это было бы слишком просто :)

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

#13
(Правка: 18:15) 17:42, 7 июля 2019

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

Есть ветка для релизов. HEAD этой ветки - последний релиз. Кроме того схемы версионирования различны. Непонятно в какую именно дату "ехать" серверу если тебе нужна версия - "34.562" или скажем "super-alfa" Как тебе помогут даты?

> Это возможно если все репы - наши, и мы сами устанавливаем правила их
> обслуживания.
Это так работает git. При всем желании отменить приказом это не получится )))

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

Ну а так выглядит, какбудто ты хочешь пользоваться инструментом и при этом одновременно игнорировать принципы его работы. Бери svn или tfs зачем тебе гит вообще при таких раскладах?

#14
18:53, 7 июля 2019

exchg
> Это бы просто "отрезало" бы половину функционала git, минимум все что связанно с ребейзом. После этого ты наверное останешься единственным кому он будет нужен.
> Есть ветка для релизов. HEAD этой ветки - последний релиз. Кроме того схемы версионирования различны. Непонятно в какую именно дату "ехать" серверу если тебе нужна версия - "34.562" или скажем "super-alfa" Как тебе помогут даты?
Та хоспаде, речь просто о том, чтобы взять машину времени, отправиться в прошлое, и сделать там git clone. Это вообще можно сделать на уровне HTTP-кеширования не трогая гит (теоретически, теоретически, спокойствие). Функционал гита тут вообще ни при чем.

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

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

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