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

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

Страницы: 1 2 3 4 59 Следующая »
#30
(Правка: 8:20) 4:51, 13 июля 2019

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

> А какую проблему вообще решает лог?
Проблему самого "контроля версий", очевидно.

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

Reflogs are useful in various Git commands, to specify the old value of a reference. For example, HEAD@{2} means "where HEAD used to be two moves ago", master@{one.week.ago} means "where master used to point to one week ago in this local repository"

Здесь мы видим то самое понятие "сорцы из репозитория, актуальные на такой-то момент времени", наличие которого тут отрицали. Получается, его вроде как и нет, но когда очень надо, то оно есть.

> Ну разумеется ты можешь предоставить ссылку на мэйл листы где ребята об этом говорят?
Это художественное обобщение :)

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

> Потому что у тебя за определенно число будет более одного состояния. И нету
> никакого способа понять какое из них актуально, а какое нет
Уточню на всякий случай, что под "датой" обычно имеется ввиду дата/время. А то такое впечатление, что это не очевидно, потому что все почему-то рассказывают про какую-то "кучу состояний на определённое число".

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

> 1. Реф лог это же и есть история изменения указателей веток, не?
Ну что-то вроде, не считая того, что она чисто локальная.

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

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

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

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

PS: Не люблю когда дискуссия рассыпается на кучу мелких цитаток, но чёт не вижу способа "засквашить" её обратно :)


#31
6:09, 13 июля 2019

exchg
> Для начала он отображает действия которые были применены к тому или иному
> объекту. И косвенно служит для восстановления случайно погибшего.
Кстати, поясните, кто-нить за рефлог.

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

А это значит, что для "команды" рефлоги бесполезны, и "команда" будет зависить от отдельного "Васи", у которого есть рефлог, потому что этот самый "Вася" ребейз и делал?!
это так или я как-то по другом?

и по-этому интернеты полнятся, разными статьями от "никогда ребейз не делайте", до "не делайте ничего кроме ребейза"

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

skalogryz
> Кстати, поясните, кто-нить за рефлог.
Это лог изменений HEADs для веток.

> Как по мне, так ребейз это жёстка дичь
Это обалденная вещь )

> Но сам ребейз откатить просто невозможно.
Да легко. ))) Смотря как его делать. Например есть ветка branch ты собрался ее перемещать. Делаешь в хеде этой ветки новый бранч pin потом перемещаешь как тебе угодно branch. Если все прошло как тебе нужно отпускаешь бранч убивая pin, если нет, то убиваешь branch + rename pin -> branch. Ну или просто идешь в реф лог и там ищешь (что, по мне, менее удобно)

Глобально их откатывать не нужно. Мне вообще пофиг зачем Вася что-то там у себя локально делал и как, это его личное дело и удобство. Следовательно инфа об этом тоже не нужна. Если ребейз был следанн в условном мэйн репозитории, то там же и останутся рефлоги как предохранитель. Очевидно давать возможность любому Васе корежить зеркала и мэин - глупо. Если репа вообще децентрализована и нету даже условных центральный узлов, то и Вася не страшен.

> Но рефлоги, они исключительно локальны.
Да.

> и "команда" будет зависить от отдельного "Васи", у которого есть рефлог, потому
> что этот самый "Вася" ребейз и делал?!
Точно также как вся команда будет завить от Васи который влил забаговай комит, который удалил что-то и т.д. Зачем вы дали Васе доступ к репе если он баран? ))) В общем ответ лежит в плоскости установленных внутри команды правил работы с репами. Эти правила зависят от разнообразных факторов и не являются универсальными законами.

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

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

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

#33
(Правка: 17:17) 16:44, 13 июля 2019

BUzer
> Здесь мы видим то самое понятие "сорцы из репозитория, актуальные на такой-то
> момент времени", наличие которого тут отрицали. Получается, его вроде как и
> нет, но когда очень надо, то оно есть.
...
> Затем, что когда проблема у ТС, то решение "бессмысленно и дорого", а когда
...
> Уточню на всякий случай, что под "датой" обычно имеется ввиду дата/время. А то

Смотри о чем речь, синтетическая "история" из трех за сутки:

a -> release -> с

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

> Ну что-то вроде, не считая того, что она чисто локальная.
Да, как я уже писал она локальна т.к. внутренние движения в репе это чисто дело ее хозяина.

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

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

Про перемещение это был ответ ТСу о том почему выбор по дате в текущей реализации git немного не о том, что он хочет т.к. дата сохраняется при изменении порядка.

> И ты просто мерджишь свою ветку с его откатом так, как будто он сделал
> реверт-коммит.
Не улавливаю разницы.

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

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

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

#34
20:14, 13 июля 2019

exchg
> Точно также как вся команда будет завить от Васи который влил забаговай комит,
> который удалил что-то и т.д. Зачем вы дали Васе доступ к репе если он баран? )))
в том и дело, что нет. Если Вася залил забагованный комит, его можно откатить, т.к. вся историческая информация есть в репе.
Так же можно откатить merge.
А вот при rebase точки откак нет. Как ты советуешь выше, её стоит создать руками. И если что-то пошло не так, то просто заменить текущее состояние дел, на созданный заранее бекап.

Проблема не в самом "Васе". Он кстати, не баран, а царь и бог, потому что умеет в ребейз (в отличии от остальной "команды").
Проблема в поддержке, и сравнений версий. Т.к. при ребейзе нету записи о сам ребейзе.
Есть несколько веток кода. В каждой из веток набор комитов может быть разный (именно по причине ребейза)
Информации о "начальном" наборе комитов нет (точнее он может быть вычленен, если смотреть в рефлог "Васи")

"начальный набор комитов" нужно хочется знать, чтобы понимать, какой логикой руководствовался разработчик, когда он делал этим комиты.
Rebase же делается постфактум.
Вернутся к состоянию кода который был в руках разработчиков на момент комитов, не получится, если
- не сделать предварительную копию ветки (перед rebase-ом)
- не иметь доступ к reflog-у "Васи".
Вот если бы этот самый "reflog" можно было бы залить на "командую" репу. Тогда всё было бы проще.

exchg
> Примерно как никогда не работайте с сырыми указателями. Тут нет единственно верного ответа.
какое удачное сравнение.

#35
(Правка: 21:40) 21:31, 13 июля 2019

skalogryz
> А вот при rebase точки откак нет.
Как же нет если есть? Для начала у каждого пользователя репы есть собственная копия. Минимум у автора ветки которую ребейзил Вася. Старая ветка (до ребейза) теперь уже обезглавленная, также остается лежать в истории до вызова GC. Максимум у каждого стянувшего + у Васи еще и логи должны лежать.

> Проблема не в самом "Васе". Он кстати, не баран, а царь и бог, потому что умеет
> в ребейз (в отличии от остальной "команды").
Ок. Он просто ошибся, бывает.

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

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

> - не сделать предварительную копию ветки (перед rebase-ом)
Зачем копия, если код уже был в руках (так написано выше) следовательно он лежит локальных репах и логах.

> - не иметь доступ к reflog-у "Васи".
для bare репы длаешь git config core.logAllRefUpdates true и балуешься с локальным рефлогом "командной" репы. Можешь сделать себе две репы на машине, первую подцепи как ремоте для второй и поиграйся.

> Вот если бы этот самый "reflog" можно было бы залить на "командую" репу. Тогда
> всё было бы проще.
В основном не нужно.

1. вместе с рефлогом ты должен будешь заливать и удаленные комиты (как мета данные) так и реальные блоки.
2. история ребейса может быть бесконечно длинной (Вася такой затейник)
3. рефлоги должны оставаться в "командной" репе? Если да, то на основании чего. Все репозитории - равноправны.

Теперь главный нюанс, Васина репа это его личная репа, это не копия "командной репы" с которой он синкается. Это отдельные полноправный, уникальный репозиторий из которого Вася делиться с миром результатом своего творчества, а не процессом его создания.

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

#36
(Правка: 22:37) 21:50, 13 июля 2019

exchg
> Старая ветка (до ребейза) теперь уже обезглавленная, также остается лежать в
> истории до вызова GC. Максимум у каждого стянувшего + у Васи еще и логи должны
> лежать.
> Так пойди к нему и спроси. ))) Если он будет упираться можешь прихватить палку, паяльник, начальника
> Зачем копия, если код уже был в руках (так написано выше) следовательно он лежит локальных репах и логах.

не вариант. Информация утеряна, в тех случаях, когда, например, репа передаётся от "команды" к "команде2".
(в целом, собирать логи по крупицам от "участников" проекта, это очень сомнительный процесс)

exchg
> для bare репы длаешь git config core.logAllRefUpdates true и балуешься с локальным рефлогом "командной" репы
вот это более реальный вариант.

имея такую информацию на руках, теоретически можно добиться того самого функционала который нужен ТС.
т.е. найти некое состояние репозитория (в ветке N), на некоторое число Х.

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

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

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

#37
0:30, 14 июля 2019

skalogryz
> не вариант. Информация утеряна, в тех случаях, когда, например, репа передаётся
> от "команды" к "команде2".
> (в целом, собирать логи по крупицам от "участников" проекта, это очень
> сомнительный процесс)
Это уже новая вводная ))) Если такое случилось, то на крайняк это можно списать на ЧП, которое решается локом репы и сборкой логов.

> имея такую информацию на руках, теоретически можно добиться того самого
> функционала который нужен ТС.
> т.е. найти некое состояние репозитория (в ветке N), на некоторое число Х.
Повторю вопрос, дано - синтетическая "история" из трех коммитов за сутки:

  a -> release -> с

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

> это классная риторика, для open-source проектов.
Это не риторика, это идеология которая стоит за работой гита.

> для корпоративных разработок с проперитарщиной, это не работает.
Не понимаю.

> зато ПМы уверены, что гит решит все проблемы с кодом, и поддержкой старого
> кода.
Ну вот тут я ничего не мог сказать. Заблуждение это или еще что. На своем опыте могу сказать напрмер пару  лет назад работал с конторой в гонконге, там сидели на SVN. Сказали, что он их устраивает, перестанет устраивать переедут на что-то другое. Им вообще на хайп было плевать. Так что если у тебя такие ПМ подумай о смене конторы. )))

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

> upd. Но вообще, случай с передачей разработки от одной команды к другой может
> быть занимательным процессом (именно в сфере корпоративной разработки)!
Обычная рутина.

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

#38
(Правка: 0:40) 0:30, 14 июля 2019

skalogryz
> (а фиг ли - отдельный полноправный, уникальный репозиторий, создание которого
> компания оплатила).
Именно так. Сколько твоя компания платит за каждый git clone path ? Если делать сильно часто, то стоимость удерживают с разработчиков? )))

> "Вот ты, Пратип, теперь будешь Вася!"
Да, кто последний тот и папа. )))

#39
0:50, 14 июля 2019

exchg
> Это уже новая вводная ))) Если такое случилось, то на крайняк это можно списать
> на ЧП, которое решается локом репы и сборкой логов.
А есть наставления по использованию Гита, как централизованной системый контроля версий?

exchg
> Повторю вопрос ... Или то что ТС думал является актуальным?
по-моему, уже говорили, что "время" идёт со временем.
Т.е. попадёт ли "release" или "c" зависит от штампа времени.
какое это имеено это будет время, вопрос абсолютно левый (и относится к автоматизированной системе сборки).

exchg
>> для корпоративных разработок с проперитарщиной, это не работает.
> Не понимаю.
Всё просто. На любом предприятии, люди - винтики. И должны быть легко взаимозаменяемы (в идеале).
Ну т.е. берём Васю, меняем на Пратипа - последствий для проекта в целом нет.
Берём "команду", меняем на "команду2" - последствий для проекта нет.
Все дисциплировано льют изменения в репу, все довольны.

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

Поддержка проекта (старых версий) - при неаккуратном ведении истории может вызывать боль.

exchg
> Так что если у тебя такие ПМ подумай о смене конторы. )))

я пришёл туда, а там уже Гит. И говорят его насадили, простым указом пера. Правда, нужно сделать сноску, что до этого SVN тоже пользовался, так себе. Ну т.е. без веток. А Гит, шёл идёт в БитБаккете, а значит есть удобная ВебМорда для веток и мёрджа. (и хорошо, что Веб Морда в ребейз не умеет... вроде бы)

И кстати,  про историю. По (обычным человеческим) нормам - сделали релиз - всё состояние репозитория, в ветку или тэг.
А эта контора этого не делает - отсутствие квалифицированных/обученых кадров - насадили же гит росчерском пера. Никто, никого, ничему не обучал.
НО, т.к. ребейзы не делали (а только мердже), то я приспокойно, по истории ветки версий наплодил. (и уже раз 6 помогло, с хот-патчами старых версий)

exchg
> Именно так. Сколько твоя компания платит за каждый git clone path ? Если делать сильно часто, то стоимость удерживают с разработчиков? )))
там платят за push с содержанием, чем за clone; где-то около 40 usd в час.

#40
(Правка: 1:51) 1:30, 14 июля 2019

skalogryz
> А есть наставления по использованию Гита, как централизованной системый
> контроля версий?
Ато! man svn. Ну, а если серьезно - зачем???

> по-моему, уже говорили, что "время" идёт со временем.
Ок, ТС заказал актуальную историю, на 12 ноября 19 года на 12:35, в результате мы имеем:

 [10:39] a -> [11:20] release -> [12:00] с
Вопрос тот же. С точки зрения логики ТС актуальным будет С, с сточки зрения автора ветки актуальное это release.  Что ему должна положить система, последний комит то, что автор ветки обозначил актуальным? Или то что ТС считает актуальным?

> Т.е. попадёт ли "release" или "c" зависит от штампа времени.
А ТС просил нечто актуальное, что можно компилить.  По мнению автора ветки это релиз, по мнению системы это С, по мнение ТСа это возможно нечто третье.

Заметь это место того, чтобы просто сказать например git co 19.02-stable и получить гарантированно стабильную версию на февраль 19 года (условно она и нужна). Это же так сложно...

> какое это имеено это будет время, вопрос абсолютно левый (и относится к
> автоматизированной системе сборки).
Рекомендую перечитать мой вопрос. Там ничего нету про время, там есть про то, что считать актуальным, и на основании чего !

> Всё просто. На любом предприятии, люди - винтики. И должны быть легко
> взаимозаменяемы (в идеале).
Это я понимаю. Я не понимаю как это связанно с идеологией гита. У вас на работе никто не делать локальные ветки (привет, у меня уже уникальный репозиторий). У вас на работе внесли собственные патчи и теперь  репозитории после клона делятся на элитные и не очень? 

> Сам факт, что есть какие-то "локальные репозитории", которые по сути
> предоставляют важную информацию, с точки зрения истории развития проекта,
> никого не волнует. Что ещё хуже, эти "локальные репозитории" индивидуальны, и
Это и правильно и не должно.

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

> Но такого, ни в одной компании нет.
Ты мне щас намекаешь, что у меня воспоминания полученные в «Rekall» ? ))))

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

> И кстати, про историю. По (обычным человеческим) нормам - сделали релиз - всё
> состояние репозитория, в ветку или тэг.
Спорно. Нету железных правил отлитых в гранит. Все зависит от процеса и необходимости. Есть несколько условно-популярных методов бранчига.

> А эта контора этого не делает - отсутствие квалифицированных/обученых кадров -
> насадили же гит росчерском пера.
> Никто, никого, ничему не обучал.
> НО, т.к. ребейзы не делали (а только мердже), то я приспокойно, по истории
> ветки версий наплодил. (и уже раз 6 помогло, с хот-патчами старых версий)
Ну это не только у вас там. И не только касательно гита. Но по теме - скачай почитай книжку, там все настолько разжевано, что просто завидно.  10 лет назад я чтобы нарыть нюансы читал "килотонны" мэйл листов разрабов. Сегодня все красиво оформлено, и уже переведенное лежит в открытом доступе и ждет тебя. )))

#41
(Правка: 2:13) 2:11, 14 июля 2019

exchg
> Личная репа это нечто личное (черновики, заметки, тесты различных идей и т.д.),
> все что необхоми и идет в релиз - шарится с другими и отправляется в "общак".

exchg
> Для начала у каждого пользователя репы есть собственная копия.
> Минимум у автора ветки которую ребейзил Вася. Старая ветка (до ребейза) теперь
> уже обезглавленная, также остается лежать в истории до вызова GC. Максимум у
> каждого стянувшего + у Васи еще и логи должны лежать.

Вернёмся к rebase-у. Если rebase сделан в общую репу, а через день на офис нападает шифровальщик и успешно теряются все локальные репы всех разработчиков.
И git config core.logAllRefUpdates, не включён, то возможно ли восстановить состояние центральной репы, до ребейза?

exchg
> > А есть наставления по использованию Гита, как централизованной системый контроля версий?
> Ато! man svn. Ну, а если серьезно - зачем???
ньюансы восстановления данных.
как видишь, я только эту тему и мусолю!

#42
2:47, 14 июля 2019

skalogryz
> Вернёмся к rebase-у. Если rebase сделан в общую репу
Ребейз делается локально, а потом результат пушится в remote. Т.е. в общем случае в remote будет просто сверху стоять результат ребейза от Васи. Если ребейз "проехался" ниже remote/master, то Вася вынужден будет делать форспуш. Если у вас битбакет (тут я не помню точно) или гитлаб(тут точно есть), там мастер (и можно опционально добавить любые другие) бранч защищен от форс пуша. Если собственный сервер, то можно запретить в настройках. Т.е. Вася прост не сможет ничего сломать. 

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

> И git config core.logAllRefUpdates, не включён, то возможно ли восстановить
> состояние центральной репы, до ребейза?
Проблемы будет с форпушем, а не ребейзом, но так слету не скажу.

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

#43
(Правка: 4:01) 3:27, 14 июля 2019

exchg
> Смотри о чем речь, синтетическая "история" из трех за сутки:
> a -> release -> с
> И что ему должна положить система последний комит или то, что автор ветки считает актуальным?
Система должна положить тот из этих коммитов, который соответствует запрашиваемой дате (если взять даты из поста 40, то да, это последний).
Я не понимаю, в чем тут неоднозначность. Если я прошу состояние на 12:35, то система должна вернуть состояние на 12:35. Какие тут ещё могут быть варианты? Если автор ветки в 12:36 залил хотфикс, и теперь, по его мнению, это должно быть "актуальной версией", это никак не меняет моего запроса к состоянию на 12:35.

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

> Не улавливаю разницы.
Разница в том, что во втором случае это может произойти автоматически.

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

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

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

#44
(Правка: 6:39) 4:14, 14 июля 2019

BUzer
> Я не понимаю, в чем тут не однозначность. Если я прошу состояние на 12:35, то
> система должна вернуть состояние на 12:35.
Ты лихо сменил требования.

upd: Но даж при таком раскладе. Давай немного абстрагируемся и представим что это не комиты гита, а просто массив таймштампов. Причем этот массив не упорядочен и содержит не уникальные элементы. Теперь неоднозначность понятна?

> это никак не меняет моего запроса к состоянию на 12:35
Потому что ты запрашиваешь некое состояние, у которого метка времени 12:35. При этом лично ты решил, что актуальность определяется временем последнего коммита. А вот ТС такова не говорил, а автор бранча вообще прямо указал что актуальным является нечто другое. А вот система нифига вообще не знает ничего про вашу актуальность. Она просто не оперирует такими понятиями.

> в которой твоя ветка могла бы поломаться, например.
Да можно просто поменять комиты местами и просто дропнуть один, это тоже ребейз, но да состояние изменит родителя и унаследует его изменения. Тут был не прав. Но еще раз основной посыл был в том что штамп остается тот же. И комит на 12:35 может стоять после комита на 18:00. Т.е. реально отображать состояние на шесть часов позже. 

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

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

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

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

upd:  Перечитал, обобщу что я имею в виду под ростом размера и необходимости пушить при наличии машины времени.

простой пример:

состояние на 12:00
a -> b -> c ->d

в 12:30 я понял, что хватанул лишка и заресетил ветку на два коммита назад и получил состояние:
a -> b

С учетом машины времени слепки c и d должны жить вечно. Т.к. я могу запросить состояние на вермя пока они были еще живы. Дальше больше. Мой локальный репозиторий и ремот вообще равноценны. Следовательно я должен запушить историю и c и d в придачу. Т.к. иначе машина времени в моей репе покажет другой результат чем в ремоте. Т.е. реальное состояние на 12:00 будет потеряно, что упраздняет весь смысл.

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