Здравствуйте, Amras Singollo, Вы писали:
BFE>>Ну так мне реально нужно иметь две рабочие копии одновременно. AS>git worktree предназначен именно для этого.
Вот оно что... Спасибо. Надо будет попробовать.
Впрочем это не делает git распределённой системой контроля версий.
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Получается, что в R2 сейчас лежат две версии: одна изменённая и одна не изменённая. BFE>·>Нет, будет одна версия, в ветке mybranch. Т.к. из R3 ты делаешь push origin XXX:mybranch BFE>Почему сделано именно так?
По-умолчанию, ибо самое простое и надёжное решение. Ты можешь сделать явно push origin XXX:anotherbranch и потом иметь явно две ветки, жонглируя ими как обычно. Или ещё есть фича "updateInstead" для push-to-deploy сценария.
BFE>>>Вопрос: в чем для R2 принципиальная разница в результате? BFE>·>Читай внимательно что я тебе пишу. Я тебе ответил уже три раза. BFE>Три раза ответили и три раза не указали принципиальную причину. Раз раз вы так зациклились на ветках, то что мешает автоматически завести ещё одну ветку для данного случая?
Принципиально ветки — именованные _человеком_ ссылки на ревизии. Автоматически ветки создавать не стоит. Но если тебе очень хочется, то ты можешь простенький алиас написать.
BFE>И что мешает при втором варианте положить изменения в ту же ветку, что и в первом варианте?
То что ветка означает ровно одну ревизию. Многоголовости нет. И не надо, спасибо.
BFE>>>В репозитарии R2 так или иначе появляются изменения. Какая разница, откуда эти изменения там появились? BFE>·>Разница в имени ветки, которая указывает на эти версии. BFE>Ну это же мелочи.
В смысле? Ты именуешь ветки сам, git имена придумывать не должен.
BFE>·>Ты наверное недопонимаешь суть веток в git, сравнивая их c mercurial. В mercurial ветки — более сложная структура их имена глобальны, что создаёт сложности для некоторых distributed сценариев. BFE>Насколько я понимаю, ветки в git — это всего лишь надстройка над хранилищем слепков состояний. Поэтому, при желании, ветки можно перестраивать в любом порядке.
Даже проще, никакая не магическая надстройка, а файлик, содержимое которого — sha1 ревизии.
BFE>·>В git ветки исключительно локальны и позволяют поддерживать произвольные distributed сценарии. BFE>В каком смысле "В git ветки исключительно локальны"? Что за ерунда? Я легко могу создать как ветку у себя, так и ветку на remote. Собственно, чтобы обойти указанное в первом сообщении темы ограничение git, я пушу изменение в клоне клона в клон задавая другую ветку, а потом мержу. Я не понимаю, почему автоматически так не сделано.
А как ты собираешься автоматически мержить через push? Если хочешь именно так, то проще всего делать pull из клона-клона в клон.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
BFE>·>В git для таких сценариев не требуется создавать клоны (как ты наверное привык в более примитивных vcs), для этого можно просто создавать локальные ветки — это работает быстрее, занимает меньше места и упрощает команды. BFE>Локальные ветки в данном случае будут только мешать. BFE>Мало того, что после каждого переключения ветки нужно пересобирать бинарник,
Ну это как-то далеко от современных практик. Если ветки отличаются немного, то инкрементальный билд работает быстро. Если различий много, то непонятно откуда такая разница окажется в одноимённой ветке.
BFE>так ещё про карманные (git stash) изменения надо помнить.
Эээ. А это зачем помнить?
BFE>>>Что в этом сложного? BFE>·>это сложнее, чем простые ветки. Клоны оправданы только в том случае, если тебе реально нужно иметь две рабочие копии одновременно. BFE>Ну так мне реально нужно иметь две рабочие копии одновременно.
До перехода на git это мне тоже неально было нужно, ибо в других vcs выбора особо нет. Потом вдруг внезапно выяснилось, то это нафиг не нужно в подавляющем большинстве случаев. Один более-менее реальный случай это когда я гонял исходники между виртуалками с разными осями.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Принципиально ветки — именованные _человеком_ ссылки на ревизии. Автоматически ветки создавать не стоит. Но если тебе очень хочется, то ты можешь простенький алиас написать.
Одним алиасом тут не обойтись. Нужно ещё, чтобы git перед операцией push предупреждал, что есть расхождения с данными пришедшими от клона.
Если я вас правильно понял, то git уже создаёт автоматические ветки: BFE>>Получается, что в R2 сейчас лежат две версии: одна изменённая и одна не изменённая. ·>Да, одна версия будет в ветке mybranch, другая в ветке remotes/origin/mybranch.
Вот "remotes/origin/mybranch" — что это, как не автоматически созданная ветка?
Что мешает создать: "clones/origin/mybranch"?
(Ещё ветка master создаётся автоматически...)
·>А как ты собираешься автоматически мержить через push?
Никакого автоматического мержа не надо.
·>Если хочешь именно так, то проще всего делать pull из клона-клона в клон.
Нет, так нельзя. Клонов может быть несколько и некоторые могут уже не существовать.
Здравствуйте, B0FEE664, Вы писали:
BFE>·>Принципиально ветки — именованные _человеком_ ссылки на ревизии. Автоматически ветки создавать не стоит. Но если тебе очень хочется, то ты можешь простенький алиас написать. BFE>Одним алиасом тут не обойтись. Нужно ещё, чтобы git перед операцией push предупреждал, что есть расхождения с данными пришедшими от клона.
Зачем предупреждать и что с этим предупреждением потом делать?
BFE>Если я вас правильно понял, то git уже создаёт автоматические ветки:
Прошу прощения. Неточно выразился. Не ветки, а имена веток.
BFE>>>Получается, что в R2 сейчас лежат две версии: одна изменённая и одна не изменённая. BFE>·>Да, одна версия будет в ветке mybranch, другая в ветке remotes/origin/mybranch. BFE>Вот "remotes/origin/mybranch" — что это, как не автоматически созданная ветка?
Нет. Это ref состоящие из префикса и имени ветки.
remotes это фиксированный префикс всех рефов, которые являются ветками (refs/remotes/... — удалённые ветки, refs/heads/... — локальные ветки, refs/tags/... — теги и т.п.). origin — это имя remote, которое назначает человек (но есть дефолтное имя origin). А mybranch как раз имя созданное в другом репе.
BFE>Что мешает создать: "clones/origin/mybranch"?
Можно создать remotes/myCloneXXX/mybranch в том случае, если ты клон добавишь как remote.
Префикс clones по-моему смысла вообще не имеет.
BFE>(Ещё ветка master создаётся автоматически...)
Это тоже дефолтное имя.
BFE>·>А как ты собираешься автоматически мержить через push? BFE>Никакого автоматического мержа не надо.
Когда ты делаешь push ветки содержат разную историю (иначе накой вообще push делать?!). А значит без merge не обойтись (как минимум ff).
BFE>·>Если хочешь именно так, то проще всего делать pull из клона-клона в клон. BFE>Нет, так нельзя. Клонов может быть несколько
Судя по тому, что ты ожидаешь от клонов — ровно так же делается и обычными remotes.
BFE>и некоторые могут уже не существовать.
В git любой репо может уже не существовать. В т.ч. и тот, что ты называешь тут сервером.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Мне обещали, что git — это distributed система, а на практике она централизованая. BFE>·>Нет, не централизована. BFE>А почему я тогда не могу из одного клона изменить другой клон?
Потому, что клоны равноправны. Можешь сделать pull из оригинального клона.
Здравствуйте, B0FEE664, Вы писали:
BFE>·>Читай внимательно что я тебе пишу. Я тебе ответил уже три раза. BFE>Три раза ответили и три раза не указали принципиальную причину.
Принципиальная причина в том, что в источнике клона файлы в рабочей копии перестанут соответствовать их последней версии в локальной ветке. Всё, больше никаких проблем нет.
Лечится такими путями:
1. Не делать так.
2. Сделать один локальный bare-репозиторий и клонировать его. (Но зачем?)
3. Отключить ограничение и разбираться потом в отпавших от кода кусочках.
Здравствуйте, B0FEE664, Вы писали:
BFE>например, может оказаться, что remote не доступен какое-то время, или BFE>допустим я внёс изменения в своей копии, но их ещё рано выкладывать в remote,
А если через локальный коммит?
LB>>Иначе получается, что из клона клона нужно пушить в оригинальный клон, а уже из него — в remote. BFE>Что в этом сложного?
Здравствуйте, Lazy Bear, Вы писали:
BFE>>например, может оказаться, что remote не доступен какое-то время, или BFE>>допустим я внёс изменения в своей копии, но их ещё рано выкладывать в remote, LB>А если через локальный коммит?
А если у меня два компьютера и я хочу сделать клон на второй?
LB>>>Иначе получается, что из клона клона нужно пушить в оригинальный клон, а уже из него — в remote. BFE>>Что в этом сложного?
LB>Похоже на легкое извращение
Тут ведь как, назвался груздем — полезай в кузов, если система распределённая, то она должна уметь делать клон клона и мержить изменения обратно. То, что у каждого своя копия не делает систему распределённой...
Здравствуйте, ·, Вы писали:
BFE>>·>Если хочешь именно так, то проще всего делать pull из клона-клона в клон. BFE>>Нет, так нельзя. Клонов может быть несколько ·>Судя по тому, что ты ожидаешь от клонов — ровно так же делается и обычными remotes.
Если всё делается обычным remotes, то как именно это делается?
Допустим у нас есть 4 компьютера (A,B,C,D), но не все они имеют сетевой доступ друг к другу. Допустим есть такая сеть:
A <--> B <--> C
| <--> D
— стрелка означает возможность доступа.
Допустим на A лежат исходники.
Как с помощью git огранизовать работу на компьютерах C и D так, чтобы результат был на A?
Здравствуйте, B0FEE664, Вы писали:
BFE>>>·>Если хочешь именно так, то проще всего делать pull из клона-клона в клон. BFE>>>Нет, так нельзя. Клонов может быть несколько BFE>·>Судя по тому, что ты ожидаешь от клонов — ровно так же делается и обычными remotes. BFE>Если всё делается обычным remotes, то как именно это делается?
В репо что ты называл /users/aaa/src делаешь git remote add klon /users/aaa/klon/prj ну и тянешь оттуда pull/fetch как обычно, делая мержи и разрешая конфликты, заталкивая результат в origin (т.е. ssh://....). Т.е. у тебя будут ветки remotes/origin/mybranch, remotes/klon/mybranch и просто mybranch, которые ты можешь сравнивать и мержить как обычно.
BFE>Допустим у нас есть 4 компьютера (A,B,C,D), но не все они имеют сетевой доступ друг к другу. Допустим есть такая сеть: BFE>
BFE> A <--> B <--> C
BFE> | <--> D
BFE>
BFE>- стрелка означает возможность доступа. BFE>Допустим на A лежат исходники. BFE>Как с помощью git огранизовать работу на компьютерах C и D так, чтобы результат был на A?
Вариантов несколько. Думаю самый простой будет если на B работать не требуется, то сделать его bare и оттуда делать push B->A того, что пришло из push C->B и D->B.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Lazy Bear, Вы писали:
BFE>>А если у меня два компьютера и я хочу сделать клон на второй? LB>Ну, у меня есть проект на двух компах. Pull-commit-push работает на обоих, ничего не ломается
Меня интересует случай, когда что-то сломалось. Например, не доступен remote на котором лежит проект.
Здравствуйте, ·, Вы писали:
BFE>>·>Судя по тому, что ты ожидаешь от клонов — ровно так же делается и обычными remotes. BFE>>Если всё делается обычным remotes, то как именно это делается? ·>В репо что ты называл /users/aaa/src делаешь git remote add klon /users/aaa/klon/prj ну и тянешь оттуда pull/fetch как обычно, делая мержи и разрешая конфликты, заталкивая результат в origin (т.е. ssh://....). Т.е. у тебя будут ветки remotes/origin/mybranch, remotes/klon/mybranch и просто mybranch, которые ты можешь сравнивать и мержить как обычно.
Т.е. всё руками. Руками я и так могу сделать. Могу даже файлы скопировать или смержить из двух каталогов. Зачем тогда нужен git?
BFE>>Допустим у нас есть 4 компьютера (A,B,C,D), но не все они имеют сетевой доступ друг к другу. Допустим есть такая сеть: BFE>>
BFE>> A <--> B <--> C
BFE>> | <--> D
BFE>>
BFE>>- стрелка означает возможность доступа. BFE>>Допустим на A лежат исходники. BFE>>Как с помощью git огранизовать работу на компьютерах C и D так, чтобы результат был на A? ·>Вариантов несколько. Думаю самый простой будет если на B работать не требуется, то сделать его bare и оттуда делать push B->A того, что пришло из push C->B и D->B.
И если на A из вне появилась новая версия, то кто разрешит конфликт c версией на B?
Здравствуйте, B0FEE664, Вы писали:
BFE>·>В репо что ты называл /users/aaa/src делаешь git remote add klon /users/aaa/klon/prj ну и тянешь оттуда pull/fetch как обычно, делая мержи и разрешая конфликты, заталкивая результат в origin (т.е. ssh://....). Т.е. у тебя будут ветки remotes/origin/mybranch, remotes/klon/mybranch и просто mybranch, которые ты можешь сравнивать и мержить как обычно. BFE>Т.е. всё руками. Руками я и так могу сделать. Могу даже файлы скопировать или смержить из двух каталогов. Зачем тогда нужен git?
Собственно да, в этом и суть — git делает естественные и простые манипуляции, которые можно делать и руками, просто с git удобнее и надёжнее. Плюс переизобретать ничего не нужно, большинство сценариев автоматизированы и документированы. А что ты ещё хотел от тупого трекера содержимого?
BFE>>>Допустим на A лежат исходники. BFE>>>Как с помощью git огранизовать работу на компьютерах C и D так, чтобы результат был на A? BFE>·>Вариантов несколько. Думаю самый простой будет если на B работать не требуется, то сделать его bare и оттуда делать push B->A того, что пришло из push C->B и D->B. BFE>И если на A из вне появилась новая версия, то кто разрешит конфликт c версией на B?
Где-нибудь в C или в D. Если push B->A проваливается, делаешь pull, затем идёшь в C, разрешаешь конфликт, потом push C->B, потом опять в B сделать push B->A.
Т.е. B это просто зеркало A.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·> А что ты ещё хотел от тупого трекера содержимого?
Хочу систему управления версиями, а не тупой трекер.
BFE>>>>Допустим на A лежат исходники. BFE>>>>Как с помощью git огранизовать работу на компьютерах C и D так, чтобы результат был на A? BFE>>·>Вариантов несколько. Думаю самый простой будет если на B работать не требуется, то сделать его bare и оттуда делать push B->A того, что пришло из push C->B и D->B. BFE>>И если на A из вне появилась новая версия, то кто разрешит конфликт c версией на B? ·>Где-нибудь в C или в D. Если push B->A проваливается, делаешь pull, затем идёшь в C, разрешаешь конфликт, потом push C->B, потом опять в B сделать push B->A.
Вот этот "делаешь pull" — где, откуда и куда? Напомню, что забрать в C из A не получится по условию задачи.
·>Т.е. B это просто зеркало A.
А в git есть что-нибудь более умное, чем зеркало? Функциональность зеркала категорически не достаточна, чтобы назвать систему распределённой.
Здравствуйте, B0FEE664, Вы писали:
BFE>·> А что ты ещё хотел от тупого трекера содержимого? BFE>Хочу систему управления версиями, а не тупой трекер.
Фобии/филии — это к врачу. Ничем помочь не могу.
BFE>>>·>Вариантов несколько. Думаю самый простой будет если на B работать не требуется, то сделать его bare и оттуда делать push B->A того, что пришло из push C->B и D->B. BFE>>>И если на A из вне появилась новая версия, то кто разрешит конфликт c версией на B? BFE>·>Где-нибудь в C или в D. Если push B->A проваливается, делаешь pull, затем идёшь в C, разрешаешь конфликт, потом push C->B, потом опять в B сделать push B->A. BFE>Вот этот "делаешь pull" — где, откуда и куда? Напомню, что забрать в C из A не получится по условию задачи.
Да, неточно выразился. Вначале fetch, A в B, потом pull с разрешением конфликта из B в C.
BFE>·>Т.е. B это просто зеркало A. BFE>А в git есть что-нибудь более умное, чем зеркало?
А зачем что-то умное, если глупого достаточно?
BFE> Функциональность зеркала категорически не достаточна, чтобы назвать систему распределённой.
Согласен. Не зеркало делает git распределённой системой, а ВНЕЗАПНО отсутствие некой центральной сущности и локальность операций и данных.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
BFE>>Хочу систему управления версиями, а не тупой трекер. ·>Фобии/филии — это к врачу.
Не стоит путать филию с хотелкой. Это разное.
·>Ничем помочь не могу.
Добавить в git новую функциональность — "не судьба"?
BFE>>·>Где-нибудь в C или в D. Если push B->A проваливается, делаешь pull, затем идёшь в C, разрешаешь конфликт, потом push C->B, потом опять в B сделать push B->A. BFE>>Вот этот "делаешь pull" — где, откуда и куда? Напомню, что забрать в C из A не получится по условию задачи. ·>Да, неточно выразился. Вначале fetch, A в B, потом pull с разрешением конфликта из B в C.
Чего-то я не понимаю. Если на bare репозитории выполнить fetch, то pull из этого репозитория заберёт ту версию, что эта fetch обновила? А в какой момент эти две ветки сольются в одну на B?
BFE>>А в git есть что-нибудь более умное, чем зеркало? ·>А зачем что-то умное, если глупого достаточно?
Для удобства. Вот если бы компьютеры вывод чисел умели бы делать только в двоичной системе исчисления, то многим это бы не понравилось. Вот и тут так же.
·>Согласен. Не зеркало делает git распределённой системой, а ВНЕЗАПНО отсутствие некой центральной сущности и локальность операций и данных.
Локальности я тут не наблюдаю: всё время "вылезает" bare репозиторий в качестве сервера.
Здравствуйте, B0FEE664, Вы писали:
BFE>·>Ничем помочь не могу. BFE>Добавить в git новую функциональность — "не судьба"?
Во-первых, ты так и не описал собственно какую функциональность ты хочешь. Те сценарии которые ты описывал — элементарно ложатся на стандартные варианты использования.
Во-вторых, поизучай возможности расширения git, может тебе стоит создать пару тривиальных альясов и магия случится.
В-третьих, это ж опенсорс, добавь сам.
BFE>>>Вот этот "делаешь pull" — где, откуда и куда? Напомню, что забрать в C из A не получится по условию задачи. BFE>·>Да, неточно выразился. Вначале fetch, A в B, потом pull с разрешением конфликта из B в C. BFE>Чего-то я не понимаю. Если на bare репозитории выполнить fetch, то pull из этого репозитория заберёт ту версию, что эта fetch обновила? А в какой момент эти две ветки сольются в одну на B?
Слитие произойдёт в C, в момент pull из B в C. На B никаких слитий не требуется делать, через него просто коммиты туда-сюда гоняются.
BFE>>>А в git есть что-нибудь более умное, чем зеркало? BFE>·>А зачем что-то умное, если глупого достаточно? BFE>Для удобства. Вот если бы компьютеры вывод чисел умели бы делать только в двоичной системе исчисления, то многим это бы не понравилось. Вот и тут так же.
Ты так и не рассказал что ты считаешь удобством. Более того, помимо зеркала тебе тут ещё несколько вариантов предлагали.
BFE>·>Согласен. Не зеркало делает git распределённой системой, а ВНЕЗАПНО отсутствие некой центральной сущности и локальность операций и данных. BFE>Локальности я тут не наблюдаю: всё время "вылезает" bare репозиторий в качестве сервера.
Можно и не bare, но это будет усложнение на пустом месте без каких-либо объективных бенефитов, хотя субъективно может показаться удобнее.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
