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

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

Страницы: 13 4 5 69 Следующая »
#45
(Правка: 6:50) 6:44, 14 июля 2019

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

давай, тогда так спрошу. Сам факт наличия "защищённых бранчей" это следствие того, что форс-push-и, откатить можно, только в том случае, если есть предыдущее состояние (общей репы) в чьей-то локальной репозитории? Если такой копии нет, то откат фактически невозможен?

rebase меняет историю (в локальной репе), и по-этому для проталкивания rebase в общую репу, нужен именно форс-пуш?

exchg
> в 12:30 я понял, что хватанул лишка и заресетил ветку на два коммита назад и
> получил состояние:
> a -> b
ключевая разница, между svn-ом и git-ом.
В git-е можно переписать, историю, в svn-е нельзя.
по-этому в svn-е, получение репозитория на время 12:00-12:29, всегда вернёт 4 файла, а после 12:30 уже только два

git всегда будет возвращать только 2, потому что они были откачены.
хотя если курить reflog-и, то можно вычленить, что reset произошёл тогда-то и тогда-то ( и на момент 12:25 файлов должно быть 4). не?

Просто 12:25 для гит репозитория, сегодня может быть 1м, а завтра может быть другим. (вдруг ты снова добавишь те два 2 файла, или ещё кучу других файлов, но которые были добавленны еща раньше).
Для свн 12:25 репозитория, всегда один и тот же. хоть завтра, хоть после завтра, хоть через 100 лет.


#46
7:06, 14 июля 2019

skalogryz
> давай, тогда так спрошу. Сам факт наличия "защищённых бранчей" это следствие
> того
Я не знаю точно чего это следствие.

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

> git всегда будет возвращать только 2, потому что они были откачены.
Да потому, что автор решил, что так правильно и не только локально, но и подтвердил это передав изменения в таком виде соседу.

> хотя если курить reflog-и, то можно вычленить, что reset произошёл тогда-то и
> тогда-то ( и на момент 12:25 файлов должно быть 4). не?
примерно так.

#47
7:10, 14 июля 2019

skalogryz
> Просто 12:25 для гит репозитория, сегодня может быть 1м, а завтра может быть
> другим. (вдруг ты снова добавишь те два 2 файла, или ещё кучу других файлов, но
> которые были добавленны еща раньше).
Примерно так, только еще хуже. ))) Я завтра могу передумать и попросить гит при очередном ребейсе обновить дату затронутых комитов на текущую.

#48
(Правка: 7:30) 7:27, 14 июля 2019

exchg
> Примерно так, только еще хуже. ))) Я завтра могу передумать и попросить гит при
> очередном ребейсе обновить дату затронутых комитов на текущую.
интересно, можно ли бухгалтера научить гиту.

#49
7:34, 14 июля 2019

exchg
> Но стоит добавить, что отсутствие копии возможно только если форспушер и есть
> автор оригинальной ветки и больше никто не скачал себе копию. Либо копия
> одновременно пропала и у форспушера и у автора оригинальной ветки.
и у всей команды сразу :)

например потому что работу над репой отдали из "команды" в "команду2"
Всё ещё есть у "команды2" это состояние основной репы...

#50
(Правка: 14:33) 14:31, 14 июля 2019

skalogryz
> интересно, можно ли бухгалтера научить гиту.
Можно даже медведя научить кататься на одноколесном велосипеде.

> и у всей команды сразу :)
Тут я исходил из того что ее вообще никто не вытянул. Т.е. она есть только у автора и в "центре".

> Всё ещё есть у "команды2" это состояние основной репы..
Ну так по задумке основная репа это и есть актуальное состояние исходников по мнению авторов. Причем то самое которые можно и нужно предавать другим.

#51
(Правка: 11:15) 4:52, 15 июля 2019

exchg
> Ты лихо сменил требования.
В смысле?

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

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

> а автор бранча вообще прямо указал что актуальным является нечто другое. А вот
> система нифига вообще не знает ничего про вашу актуальность. Она просто не
> оперирует такими понятиями.
Ты себе противоречишь. Как мог автор бранча "прямо указать" актуальный коммит, если система не оперирует такими понятиями?

К тому же, мы ведь это уже проезжали (когда кое-кому надо, то система всё знает, и прекрасно оперирует такими понятиями, как "где был master неделю назад").

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

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

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

#52
12:01, 15 июля 2019

BUzer
> В смысле?
В прямом. Они были - получить актуальное состояние на заданное время. Ты их свел к - получить последний комит на заданное время.. Т.е. ты определил что актуальное это последний комит. А в оригинале такова не было.

> Да, но я не понимаю, какое это имеет отношение к тому, о чём я говорю.
> речь идёт не о том, как искать актуальный коммит в графе
> а о том, как можно было бы его найти,
Да я понимаю. И говорю, что лопата не может знать зачем человек копает яму. Следовательно в общем случае найти однозначно  актуальный для тебя или ТС комит нельзя. И привожу пример:

a -> release -> с

В котором автор явно указал, что для него актуальное состояние это release, остальное это промежуточные этапы. Для кого-то  таким актуальным может оказаться самый последний комит С, а для лопаты git они вообще все равнозначны т.к. лопата не знает, что там хотят субъекты на самом деле.

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

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

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

> но так далеко я ещё не задумывал :)
Так а без такова ваша с ТС машина времени работать не будет.

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

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

Например skalogryz вот переживает за сохран данных. И, например, в этом свете он может сделать промежуточный репозиторий для "рабочей группы"

bitbucket                                                                                                                                                                                                       
      +----- midrepo A                                                                                                                                                                                             
              +----- user A local repo                                                                                                                                                                           
              +----- ...                                                                                                                                                                                         
              +----- user D local repo

      +----- midrepo B                                                                                                                                                                                             
              +----- user E local repo                                                                                                                                                                           
              +----- user F local repo

Где на bitbucket лежит актуальное и дорогое для фирмы. midrepo - клон bitbucket  (возможно частичный)  + общие ветки для группы. localrepo - клон midrepo  (возможно частичный) + локальные ветки и разные личное творчество. Разнеси это все территориально + только маинтейнеры midrepo пушат на bitbucket и форспуш + шифровальщик уже не страшно.

Это я веду к тому что при такой схеме мне вообще трудно представить зачем в bitbucket нужны истории изменений неких веток +  мертвые комиты от "машины времени", которые непонятно зачем делались в неких третьих местах.

#53
15:07, 15 июля 2019

exchg
> В прямом. Они были - получить актуальное состояние на заданное время. Ты их
> свел к - получить последний комит на заданное время.
Погоди, Я СВЁЛ??? В посте 33 ТЫ задал мне вопрос, подразумевая один из двух ответов:
> И что ему должна положить система последний комит или то, что автор ветки считает актуальным?
Я же про последний коммит до этого ничего не говорил. Если кто и свёл, то это ты.

> И говорю, что лопата не может знать зачем человек копает яму. Следовательно
"Следовательно"? То, что ты сказал — это метафора. Из неё ничего не следует.

> в общем случае найти однозначно актуальный для тебя или ТС комит нельзя.
"Общий случай" — это что за случай такой? Это когда мы ищем коммиты на флэшке одного из разрабочиков, которую он увёз к себе в деревню, где нет интернета, чтобы поработать на выходных? Или он всё-таки он "общий" в каких-то более адекватных рамках? Если да, то дело за малым: установить "границы применимости" для нашего "инструмента поиска актуального коммита", и больше не волноваться о том, что его нельзя применить за их пределами.

> В котором автор явно указал, что для него актуальное состояние это release, остальное это промежуточные этапы.
Как указал, написав коммит мессадж что ли? Да мало ли, что он там написал. Ай донт спик инглишь, я не знаю, что он там имеет ввиду. А спустя пару коммитов написано hotfix — теперь это актуальный коммит? Чё-то мне не "явно" это ни разу. Он мог с тем же успехом в емейле боссу написать хэш коммита, и такое указание актуальности было бы "явным" в той же степени. Анализ писанины автора вообще не входит в область решаемой задачи.

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

> Потому, что чужой и его неизвестная история не интересна
Прощу прощения, ват? А смысле, што? Кому "не интересна"? Мне вот интересна.

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

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

#54
15:57, 15 июля 2019

BUzer
> Ну капец, теперь выясняется, что проблему получения состояния репозитория на
> заданную дату невозможно решить ...
> И как только svn и tfs без этого обходятся?
я хз как в tfs, но в svn историю переписывать нельзя.
в git-е можно.
Но если в репе гита не использовать перепись истории, то "получение состояние на заданую дату" становится вполне возможным.

Опять же, проблема упрёться, в конкретных пользователей Гита.
Т.е. если люди свободно оперируют возможностью изменения истории, то обязательно будут говорить, что "такой функционал бессмысленнен, и ты делаешь всё не так".

#55
18:29, 15 июля 2019

BUzer
> Погоди, Я СВЁЛ??? В посте 33 ТЫ задал мне вопрос, подразумевая один из двух
> ответов:
Да. Ты. Я же наоборот говорю, что понять что такое актуальный ни мы ни гит не можем. )))

> Я же про последний коммит до этого ничего не говорил. Если кто и свёл, то это
> ты.
Ок. Повторю еще раз. Я говорю, что имею историю на заданное время (до секунды):

[12:30:32] a -> [12:30:32] release -> [12:30:32] c

Мы переходим ко второй части задачи, а именно - определению актуальности. Очевидно, что автор ветки нам  "намекает", что это release, что тут будет актуальным по мнению ТС пока загадка. Был вариант, что актуальным считать самый поздний комит. И вот я тебе снова задаю вопрос. Какой из этих трех комитов система должна положить ТСу в дерево для компиляции ?

> То, что ты сказал — это метафора.
Нет, это аналогия.

> "Общий случай" — это что за случай такой?
Это то, который который без граничных условий.

> Если да, то дело за малым: установить "границы применимости" для нашего
> "инструмента поиска актуального коммита", и больше не волноваться о том, что
> его нельзя применить за их пределами.
Конечно. И эти границы такие - ваш метод работает только в том случае если будет всего один комит имеющий штамп равный запрошенному к нему не применялся ребейз.

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

> Как указал, написав коммит мессадж что ли?
Именно. Хотя обычно для этого используют теги.

> А спустя пару коммитов написано hotfix — теперь это актуальный коммит?
А спустя пару комитов это уже другой временно промежуток.

> Чё-то мне не "явно" это ни разу. Он мог с тем же успехом в емейле боссу
да нивапрос же!!! пусть же история будет вот такой:

[12:30:32] a -> [12:30:32] most actual!!! -> [12:30:32] c

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

> Это не проблема, т.к. даже несмотря на то, что у изменений одинаковое время,
...
> Поэтому результат всех этих изменений однозначен, и для задачи поиска по
> времени их можно рассматривать как одно большое изменение.
Ну так ответь уж на вопрос, который из этих трех должен лежать у ТСа в дереве:

[12:30:32] a -> [12:30:32] most actual!!! -> [12:30:32] c

> Прощу прощения, ват? А смысле, што? Кому "не интересна"?
Репозиторию А не интересна история изменений head определенной векти в репозитории Б. Ему может быть интересен конечный результат этих изменений.

> Мне вот интересна.
Судя по отсутствию данного функционала в гите ты один либо вас исчезающе мало. ))))

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

> Тьюринга. И как только svn и tfs без этого обходятся?..
Хотел шуткануть, что они обходятся не только без капчи, но и без пользователей, но потом передумал. Наверно потому, что у них кардинально другая идеология и их пользователи мыслят исключительно в парадигме server(master) / client(slave)?

#56
18:42, 15 июля 2019

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

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

#57
20:37, 15 июля 2019

exchg
> Нету обсалютно верных правил отлитых в граните. Правильность определяешь ты сам
> исходя из задач и возможностей инструмента.
есть одно абсолютное правило человеческой жизни - нельзя вернутся в прошлое.
И гит, при определённом использовании его только усиливает :D

#58
21:21, 15 июля 2019

skalogryz
> есть одно абсолютное правило человеческой жизни - нельзя вернутся в прошлое.
> И гит, при определённом использовании его только усиливает :D
Возврат в прошлое без возможности его изменить имеет в два раза меньше смысла чем с такой возможностью!1 ))

#59
5:34, 17 июля 2019

exchg
> И вот я тебе снова задаю вопрос. Какой из этих трех комитов система должна
> положить ТСу в дерево для компиляции ?
Строго говоря, здесь недостаточно данных, чтобы ответить на этот вопрос. Как я уже сказал (несколько раз), для нормальной истории нам нужен "рефлог". Поэтому помимо самих коммитов, тут надо также привести содержимое лога интересующей нас ветви.
Ну хорошо, для краткости предположим, что сущности "a", "release", и "c" в твоём примере — это записи в логе, которые ссылаются на коммиты с соответствующими именами. Нетрудно заметить, что все эти записи, имея одинаковый тайм штамп, попадают под все условия, которые я описал в предыдущем посте:
> расположены в определённом порядке по отношению друг к другу, и между ними ничего другого нет. Поэтому результат всех этих изменений однозначен, и для задачи поиска по времени их можно рассматривать как одно большое изменение.
Результат этого одного большого изменения определяется состоянием, содержащимся по крайней правой ссылке, поэтому если юзер делает запрос на 12:30:32, то ответом будет коммит "c".

> Нет, это аналогия.
У аналогии есть как минимум одно сходство с метафорой — из них обоих ничего не следует :)

> ваш метод работает только в том случае если будет всего один комит имеющий
> штамп равный запрошенному к нему не применялся ребейз.
Что с тобой не так? Я уже кучу раз сказал, что мне пофиг на штамп времени, записанный в коммите. Откуда ты постоянно эту чушь берешь? Сначала выдумываешь что-то, а потом жалуешься, будто я условия меняю.

> Репозиторию А не интересна история изменений head определенной векти в
> репозитории Б. Ему может быть интересен конечный результат этих изменений.
… и на чём это заявление основано? Репозиторий — это вообще не одушевлённая вещь, если что. Ей не может быть что-то интересно и не интересно.

> Судя по отсутствию данного функционала в гите ты один либо вас исчезающе мало. ))))
Аргумент из разряда "если ты такой умный, то почему ещё не президент?" )

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

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