Потом перешёл в другой каталог и сделал клон клона:
cd /users/aaa/
mkdir klon
cd klon
git clone file:///users/aaa/src
потом изменил файл в /users/aaa/klon ...
следующие команды проходят:
cd /users/aaa/klon/prj
git add .
git commit -m "test"
А вот git push ломается со словами:
refusing to update checked out branch: ....
By default, updating the current branch in a non-bare repository
is denied, because it will make the index and work tree inconsistent
with what you pushed, and will require 'git reset --hard' to match
the work tree to HEAD.
Что это? Почему? Как это может быть, чтобы index and work tree могли поломаться? Ни рабочие файлы, ни staging area никак не могут быть задеты! Ведь эта команда ничем по смыслу не отличается от выполнения git fetch в /users/aaa/src. Бред какой-то!
Здравствуйте, B0FEE664, Вы писали:
BFE>Что это? Почему? Как это может быть, чтобы index and work tree могли поломаться? Ни рабочие файлы, ни staging area никак не могут быть задеты!
Задевается ветка, на которую указывает HEAD, т.е. то чему staging должен соответствовать.
Просто прочитай сообщение повнимательнее сообщение, суть: "it will make the index and work tree inconsistent".
Ты сделал клон /users/aaa/src. В этом каталоге у тебя теперь рабочая копия текущей ветки.
Когда ты делаешь push в /users/aaa/src в ту же ветку, то у тебя получится, что эта ветка будет другой, но файлы рабочей копии будут старыми и репо получится в интересном положении.
Другими словами, беда возникла из-за того, что ты сделал push в non-bare репо и файлы не будут больше соответствовать содержимому ветки.
BFE>Ведь эта команда ничем по смыслу не отличается от выполнения git fetch в /users/aaa/src. Бред какой-то!
git fetch выполняет fetch в FETCH_HEAD или в "remote/XXX/mybranch", а когда делают push, то менятся собственно сам "mybranch".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
BFE>>Что это? Почему? Как это может быть, чтобы index and work tree могли поломаться? Ни рабочие файлы, ни staging area никак не могут быть задеты! ·>Задевается ветка, на которую указывает HEAD, т.е. то чему staging должен соответствовать.
И почему это она должна как-то "задеваться"?
·>Просто прочитай сообщение повнимательнее сообщение, суть: "it will make the index and work tree inconsistent".
Это какие-то отговорки.
·>Ты сделал клон /users/aaa/src. В этом каталоге у тебя теперь рабочая копия текущей ветки.
Да. Копия.
·>Когда ты делаешь push в /users/aaa/src в ту же ветку, то у тебя получится, что эта ветка будет другой, но файлы рабочей копии будут старыми и репо получится в интересном положении.
Если я делаю push на сервер, то рабочие копии других пользователей остаются старыми и репо в интересное положение не переходит.
·>Другими словами, беда возникла из-за того, что ты сделал push в non-bare репо и файлы не будут больше соответствовать содержимому ветки.
Скорее от того, что кто-то не подумал об этом сценарии.
BFE>>Ведь эта команда ничем по смыслу не отличается от выполнения git fetch в /users/aaa/src. Бред какой-то! ·>git fetch выполняет fetch в FETCH_HEAD или в "remote/XXX/mybranch", а когда делают push, то менятся собственно сам "mybranch".
Не, "mybranch" уже изменён локально, а push меняет "mybranch" на удалённой машине, т.е. в "remote/XXX/mybranch".
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Что это? Почему? Как это может быть, чтобы index and work tree могли поломаться? Ни рабочие файлы, ни staging area никак не могут быть задеты! BFE>·>Задевается ветка, на которую указывает HEAD, т.е. то чему staging должен соответствовать. BFE>И почему это она должна как-то "задеваться"?
Потому что ты в неё пушишь.
BFE>·>Просто прочитай сообщение повнимательнее сообщение, суть: "it will make the index and work tree inconsistent". BFE>Это какие-то отговорки.
Ты себя агрессивно ведёшь.
BFE>·>Ты сделал клон /users/aaa/src. В этом каталоге у тебя теперь рабочая копия текущей ветки. BFE>Да. Копия.
И репозиторий тоже, в каталоге .git. Разберись что такое non-bare repo.
BFE>·>Когда ты делаешь push в /users/aaa/src в ту же ветку, то у тебя получится, что эта ветка будет другой, но файлы рабочей копии будут старыми и репо получится в интересном положении. BFE>Если я делаю push на сервер,
Когда ты делаешь push из /users/aaa/klon в /users/aaa/src "сервером" является /users/aaa/src. А тот ssh://.... вообще никакого отношения не имеет. Это же distributed vcs. Каждый клон — это автономный репозиторий.
BFE>то рабочие копии других пользователей остаются старыми и репо в интересное положение не переходит.
Если ты под сервером понимаешь ssh://.... то у него нет рабочих копий вообще, скорее всего, т.к. он bare, а про клоны и уж тем более рабочие копии других пользователей он ничего не знает и знать не может.
BFE>·>Другими словами, беда возникла из-за того, что ты сделал push в non-bare репо и файлы не будут больше соответствовать содержимому ветки. BFE>Скорее от того, что кто-то не подумал об этом сценарии.
Ну так подумай.
BFE>>>Ведь эта команда ничем по смыслу не отличается от выполнения git fetch в /users/aaa/src. Бред какой-то! BFE>·>git fetch выполняет fetch в FETCH_HEAD или в "remote/XXX/mybranch", а когда делают push, то менятся собственно сам "mybranch". BFE>Не, "mybranch" уже изменён локально, а push меняет "mybranch" на удалённой машине, т.е. в "remote/XXX/mybranch".
"remote/XXX/mybranch" в локальном репо соответсвует как правило "mybranch" в ремотном. Это же distributed vcs.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
BFE>>>>Что это? Почему? Как это может быть, чтобы index and work tree могли поломаться? Ни рабочие файлы, ни staging area никак не могут быть задеты! BFE>>·>Задевается ветка, на которую указывает HEAD, т.е. то чему staging должен соответствовать. BFE>>И почему это она должна как-то "задеваться"? ·>Потому что ты в неё пушишь.
Я пушу на сервер, а что-где лежит в репозитории определяет git.
BFE>>·>Просто прочитай сообщение повнимательнее сообщение, суть: "it will make the index and work tree inconsistent". BFE>>Это какие-то отговорки. ·>Ты себя агрессивно ведёшь.
Мне обещали, что git — это distributed система, а на практике она централизованая.
BFE>>·>Ты сделал клон /users/aaa/src. В этом каталоге у тебя теперь рабочая копия текущей ветки. BFE>>Да. Копия. ·>И репозиторий тоже, в каталоге .git.
Именно! ·> Разберись что такое non-bare repo.
Так я как раз и разобрался. non-bare repo — это обычная repo у которой нет рабочих копий.
BFE>>·>Когда ты делаешь push в /users/aaa/src в ту же ветку, то у тебя получится, что эта ветка будет другой, но файлы рабочей копии будут старыми и репо получится в интересном положении. BFE>>Если я делаю push на сервер, ·>Когда ты делаешь push из /users/aaa/klon в /users/aaa/src "сервером" является /users/aaa/src. А тот ssh://.... вообще никакого отношения не имеет. Это же distributed vcs. Каждый клон — это автономный репозиторий.
Да! В этом то и проблема! Если клон — это автономный репозиторий distributed vcs, то он должен вести себя неотличимо от "сервера".
BFE>>то рабочие копии других пользователей остаются старыми и репо в интересное положение не переходит. ·>Если ты под сервером понимаешь ssh://.... то у него нет рабочих копий вообще, скорее всего, т.к. он bare, а про клоны и уж тем более рабочие копии других пользователей он ничего не знает и знать не может.
Вот именнно. Об этом я и говорю. "Вот тут переходим, а вот тут не переходим" — это не правильное поведение. Клон на то и клон, чтобы от оригинала не отличаться.
BFE>>·>Другими словами, беда возникла из-за того, что ты сделал push в non-bare репо и файлы не будут больше соответствовать содержимому ветки. BFE>>Скорее от того, что кто-то не подумал об этом сценарии. ·>Ну так подумай.
Вот. Подумал. Потому и пишу.
BFE>>>>Ведь эта команда ничем по смыслу не отличается от выполнения git fetch в /users/aaa/src. Бред какой-то! BFE>>·>git fetch выполняет fetch в FETCH_HEAD или в "remote/XXX/mybranch", а когда делают push, то менятся собственно сам "mybranch". BFE>>Не, "mybranch" уже изменён локально, а push меняет "mybranch" на удалённой машине, т.е. в "remote/XXX/mybranch". ·>"remote/XXX/mybranch" в локальном репо соответсвует как правило "mybranch" в ремотном.
Что значит "как правило"? И что значит "соответсвует"? В remote репо лежит одна, быть может кем-то изменённая копия, в локальном репо лежит другая, быть может изменённая мною копия. А так ли это важно, каким образом я изминил локальный репо: с помощью commit'а или с помощью push'а из второй локальной копии?
·>Это же distributed vcs.
В теории. А на практике — нет.
Здравствуйте, B0FEE664, Вы писали:
BFE>>>И почему это она должна как-то "задеваться"? BFE>·>Потому что ты в неё пушишь. BFE>Я пушу на сервер, а что-где лежит в репозитории определяет git.
Во-первых, "сервер" тут не причём. В контексте пуша понятия "сервер" нет. Есть понятие remote. Так что делаешь пуш в ремотный репо. В команде пуш _всегда_ есть (иногда неявно) имя ветки в которую происходит пуш.
BFE>>>Это какие-то отговорки. BFE>·>Ты себя агрессивно ведёшь. BFE>Мне обещали, что git — это distributed система, а на практике она централизованая.
Нет, не централизована.
BFE>·> Разберись что такое non-bare repo. BFE>Так я как раз и разобрался. non-bare repo — это обычная repo у которой нет рабочих копий.
Это ошибка.
bare repository — a repository that doesn’t contain a working directory.
Соответственно non-bare repo это такой repo у которого есть working directory.
BFE>>>Если я делаю push на сервер, BFE>·>Когда ты делаешь push из /users/aaa/klon в /users/aaa/src "сервером" является /users/aaa/src. А тот ssh://.... вообще никакого отношения не имеет. Это же distributed vcs. Каждый клон — это автономный репозиторий. BFE>Да! В этом то и проблема! Если клон — это автономный репозиторий distributed vcs, то он должен вести себя неотличимо от "сервера".
Есть различие bare и non-bare репозиториев. По очевидной причине.
BFE>>>то рабочие копии других пользователей остаются старыми и репо в интересное положение не переходит. BFE>·>Если ты под сервером понимаешь ssh://.... то у него нет рабочих копий вообще, скорее всего, т.к. он bare, а про клоны и уж тем более рабочие копии других пользователей он ничего не знает и знать не может. BFE>Вот именнно. Об этом я и говорю. "Вот тут переходим, а вот тут не переходим" — это не правильное поведение. Клон на то и клон, чтобы от оригинала не отличаться.
А какое поведение ты считаешь правильным в таком сценарии?
BFE>>>·>git fetch выполняет fetch в FETCH_HEAD или в "remote/XXX/mybranch", а когда делают push, то менятся собственно сам "mybranch". BFE>>>Не, "mybranch" уже изменён локально, а push меняет "mybranch" на удалённой машине, т.е. в "remote/XXX/mybranch". BFE>·>"remote/XXX/mybranch" в локальном репо соответсвует как правило "mybranch" в ремотном. BFE>Что значит "как правило"?
Дефолтное поведение, которое можно переопределить.
BFE>И что значит "соответсвует"?
Изучай что такое branch tracking.
BFE>В remote репо лежит одна, быть может кем-то изменённая копия, в локальном репо лежит другая, быть может изменённая мною копия. А так ли это важно, каким образом я изминил локальный репо: с помощью commit'а или с помощью push'а из второй локальной копии?
Когда ты делаешь в /users/aaa/src "git commit", то ты из файлов working tree создаёшь новый snapshot, для которого генерится commit-id. Потом значение этого commit-id присваивается имени "mybranch". Поэтому после этой команды у тебя файлы в working tree соответствуют тому на что указывает mybranch.
Когда ты делаешь push откуда-то в /users/aaa/src в ветку "mybranch", то происходит то же самое присвоение commit-id этому имени. Однако, очевидно, файлы working tree менять нельзя и в итоге содержимое файлов разъезжается с содержимым ветки.
Поэтому, _если_ HEAD указывает mybranch, то git об этом и говорит, что это может привести к интересному положению и так делать не стоит (но можно, если очень хочется).
BFE>·>Это же distributed vcs. BFE>В теории. А на практике — нет.
Неверно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
BFE>>Я пушу на сервер, а что-где лежит в репозитории определяет git. ·>Во-первых, "сервер" тут не причём. В контексте пуша понятия "сервер" нет. Есть понятие remote. Так что делаешь пуш в ремотный репо. В команде пуш _всегда_ есть (иногда неявно) имя ветки в которую происходит пуш.
Ок, я пушу в remote в какую-то ветку. Это ничего не меняет.
BFE>>Мне обещали, что git — это distributed система, а на практике она централизованая. ·>Нет, не централизована.
А почему я тогда не могу из одного клона изменить другой клон?
BFE>>·> Разберись что такое non-bare repo. BFE>>Так я как раз и разобрался. non-bare repo — это обычная repo у которой нет рабочих копий. ·>Это ошибка. ·>
bare repository — a repository that doesn’t contain a working directory.
·>Соответственно non-bare repo это такой repo у которого есть working directory.
Да? И в чём же ошибка? У non-bare repo нет working directory, я это и имел ввиду.
BFE>>Да! В этом то и проблема! Если клон — это автономный репозиторий distributed vcs, то он должен вести себя неотличимо от "сервера". ·>Есть различие bare и non-bare репозиториев. По очевидной причине.
Различие есть, а быть его не должно.
·>А какое поведение ты считаешь правильным в таком сценарии?
push должен проходить туда откуда взят репозитарий, если не выставленно ограничение на запись.
BFE>>В remote репо лежит одна, быть может кем-то изменённая копия, в локальном репо лежит другая, быть может изменённая мною копия. А так ли это важно, каким образом я изминил локальный репо: с помощью commit'а или с помощью push'а из второй локальной копии? ·>Когда ты делаешь в /users/aaa/src "git commit", то ты из файлов working tree создаёшь новый snapshot, для которого генерится commit-id. Потом значение этого commit-id присваивается имени "mybranch". Поэтому после этой команды у тебя файлы в working tree соответствуют тому на что указывает mybranch.
пока всё хорошо
·>Когда ты делаешь push откуда-то в /users/aaa/src в ветку "mybranch", то происходит то же самое присвоение commit-id этому имени. Однако, очевидно, файлы working tree менять нельзя и в итоге содержимое файлов разъезжается с содержимым ветки.
Ну да. А ещё содержимое файлов так же "разъезжается", когда я делаю fetch из remote.
·>Поэтому, _если_ HEAD указывает mybranch, то git об этом и говорит, что это может привести к интересному положению и так делать не стоит (но можно, если очень хочется).
Тогда тоже самое он должен говорить на каждый pull
BFE>>В теории. А на практике — нет. ·>Неверно.
Это наблюдаемый факт.
Здравствуйте, B0FEE664, Вы писали:
BFE>>>Я пушу на сервер, а что-где лежит в репозитории определяет git. BFE>·>Во-первых, "сервер" тут не причём. В контексте пуша понятия "сервер" нет. Есть понятие remote. Так что делаешь пуш в ремотный репо. В команде пуш _всегда_ есть (иногда неявно) имя ветки в которую происходит пуш. BFE>Ок, я пушу в remote в какую-то ветку. Это ничего не меняет.
Ты не читаешь что я тебе пишу.
Повторяю. Если эта самая ветка в данный момент зачекаутина в том remote, то там возникнет несоответствие между зачекаутенными файлами и этой веткой.
BFE>>>Мне обещали, что git — это distributed система, а на практике она централизованая. BFE>·>Нет, не централизована. BFE>А почему я тогда не могу из одного клона изменить другой клон?
Я — могу. Почему ты не можешь, я сказать затрудняюсь, я не врач.
BFE>>>·> Разберись что такое non-bare repo. BFE>>>Так я как раз и разобрался. non-bare repo — это обычная repo у которой нет рабочих копий. BFE>·>Это ошибка. BFE>·>
bare repository — a repository that doesn’t contain a working directory.
BFE>·>Соответственно non-bare repo это такой repo у которого есть working directory. BFE>Да? И в чём же ошибка? У non-bare repo нет working directory, я это и имел ввиду.
Ты издеваешься что ли? Для особых дибилов:
"У non-bare repo нет working directory" — говоришь ты
"У non-bare repo есть working directory" — говорит дока.
BFE>>>Да! В этом то и проблема! Если клон — это автономный репозиторий distributed vcs, то он должен вести себя неотличимо от "сервера". BFE>·>Есть различие bare и non-bare репозиториев. По очевидной причине. BFE>Различие есть, а быть его не должно.
Ты троллишь что-ли?
BFE>·>А какое поведение ты считаешь правильным в таком сценарии? BFE>push должен проходить туда откуда взят репозитарий, если не выставленно ограничение на запись.
git так и работает по умолчанию.
BFE>·>Когда ты делаешь push откуда-то в /users/aaa/src в ветку "mybranch", то происходит то же самое присвоение commit-id этому имени. Однако, очевидно, файлы working tree менять нельзя и в итоге содержимое файлов разъезжается с содержимым ветки. BFE>Ну да. А ещё содержимое файлов так же "разъезжается", когда я делаю fetch из remote.
Я тебе это уже объяснял. fetch забирает всегда в другую ветку. Либо FETCH_HEAD, либо remote/origin/mybranch.
BFE>·>Поэтому, _если_ HEAD указывает mybranch, то git об этом и говорит, что это может привести к интересному положению и так делать не стоит (но можно, если очень хочется). BFE>Тогда тоже самое он должен говорить на каждый pull
pull это просто комбинация fetch и merge (по умолчанию)
BFE>>>В теории. А на практике — нет. BFE>·>Неверно. BFE>Это наблюдаемый факт.
Это твоё невежество.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, B0FEE664, Вы писали:
BFE>А вот git push ломается со словами: BFE>
BFE>refusing to update checked out branch: ....
BFE>By default, updating the current branch in a non-bare repository
BFE>is denied, because it will make the index and work tree inconsistent
BFE>with what you pushed, and will require 'git reset --hard' to match
BFE>the work tree to HEAD.
BFE>Что это? Почему? Как это может быть, чтобы index and work tree могли поломаться? Ни рабочие файлы, ни staging area никак не могут быть задеты! Ведь эта команда ничем по смыслу не отличается от выполнения git fetch в /users/aaa/src. Бред какой-то!
В меркуриале ничего не ломается и все замечательно пушится. Переходите на меркуриал!
Здравствуйте, B0FEE664, Вы писали:
BFE>Последний год всё глубже погружаюсь в дебри git.
BFE>Допустим я взял с некого сервера исходники: BFE>Потом перешёл в другой каталог и сделал клон клона:
Но зачем?! Почему просто не сделать бранч в оригинальном клоне с сервера, провести в этом бранче необходимые изменения и (если нужно) смержить обратно в remote?
Иначе получается, что из клона клона нужно пушить в оригинальный клон, а уже из него — в remote.
Здравствуйте, reson, Вы писали:
BFE>>Что это? Почему? Как это может быть, чтобы index and work tree могли поломаться? Ни рабочие файлы, ни staging area никак не могут быть задеты! Ведь эта команда ничем по смыслу не отличается от выполнения git fetch в /users/aaa/src. Бред какой-то! R>В меркуриале ничего не ломается и все замечательно пушится. Переходите на меркуриал!
В git тоже ничего не ломается. Суть в том, что есть проблема разъезжания истории между клонами. В меркуриале эта проблема не решается, а заметается под коврик — неявно создаётся diverged история (кошмарик, называемый многоголовый бранч) и юзеру потом это придётся разгребать. git честно предупреждает о проблеме и юзеру можно выбрать как он хочет решить проблему.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Здравствуйте, reson, Вы писали:
BFE>>>Что это? Почему? Как это может быть, чтобы index and work tree могли поломаться? Ни рабочие файлы, ни staging area никак не могут быть задеты! Ведь эта команда ничем по смыслу не отличается от выполнения git fetch в /users/aaa/src. Бред какой-то! R>>В меркуриале ничего не ломается и все замечательно пушится. Переходите на меркуриал! ·>В git тоже ничего не ломается. Суть в том, что есть проблема разъезжания истории между клонами. В меркуриале эта проблема не решается, а заметается под коврик — неявно создаётся diverged история (кошмарик, называемый многоголовый бранч) и юзеру потом это придётся разгребать. git честно предупреждает о проблеме и юзеру можно выбрать как он хочет решить проблему.
В меркуриале считается, что в рабочем каталоге могут быть файлы из любой ветки и есть отдельная команда, которая из ветки в рабочий каталог сохраняет изменения (hg update). Для распределенной системы версионного хранения ситуация с многими ветками и соответственно головами считается нормальной. При желании можно их слить, это типовая операция. И поэтому нет необходимости вводить лишние сущности — bare и обычные репозитарии.
Здравствуйте, ·, Вы писали:
BFE>>·>Когда ты делаешь push откуда-то в /users/aaa/src в ветку "mybranch", то происходит то же самое присвоение commit-id этому имени. Однако, очевидно, файлы working tree менять нельзя и в итоге содержимое файлов разъезжается с содержимым ветки. BFE>>Ну да. А ещё содержимое файлов так же "разъезжается", когда я делаю fetch из remote. ·>Я тебе это уже объяснял. fetch забирает всегда в другую ветку. Либо FETCH_HEAD, либо remote/origin/mybranch.
Почему push клона не может отдавать свои изменения по похожей схеме?
Пусть есть исходный репозитарий R1.
Я делаю git clone и получаю локальную копию — репозитарий R2,
После этого я делаю локальную копию из R2 и получаю репозитарий R3.
Схема простая: R1 --clone--> R2 --clone--> R3
Рассмотрим второго пользователя, который делает свою копию репозитария взяв за основу R1. Назовём репозитарий второго пользователя U2.
Схема:
R1 --clone--> R2 --clone--> R3
\--clone--> U2
С этого момента рассмотрим два варианта:
1) вариант первый:
Предположим, что второй пользователь изменил и запушил своё измение в репозитарий R1
R1 -----clone--> R2 --clone--> R3
\--<--push--<- U2
Теперь я вижу, что в основном репозитарии изменилась версия и могу забрать изменения командой fetch
R1 -----fetch--> R2 --clone--> R3
\--<--push--<- U2
Получается, что в R2 сейчас лежат две версии: одна изменённая и одна не изменённая.
2) вариант второй:
Предположим, что второй пользователь ничего не менял и не пушил.
А я внёс изменения в R3 и мне запушил эти изменения в R2:
R1 --clone--> R2 <--push-- R3
\--clone--> U2
Получается, что в R2 сейчас лежат две версии: одна изменённая и одна не изменённая.
Вопрос: в чем для R2 принципиальная разница в результате?
В репозитарии R2 так или иначе появляются изменения. Какая разница, откуда эти изменения там появились?
Здравствуйте, Lazy Bear, Вы писали:
BFE>>Допустим я взял с некого сервера исходники: BFE>>Потом перешёл в другой каталог и сделал клон клона:
LB>Но зачем?! Почему просто не сделать бранч в оригинальном клоне с сервера, провести в этом бранче необходимые изменения и (если нужно) смержить обратно в remote?
На это могут быть различные причины:
например, может оказаться, что remote не доступен какое-то время, или
допустим я внёс изменения в своей копии, но их ещё рано выкладывать в remote, при этом эти изменения мне нужны ещё для одной версии, которая будет разрабатываться параллельно с первой. Я, конечно, могу, завести ещё одну ветку, выложить эту ветку в remote и оттуда её забрать в другой локальный каталог. Т.е. создать ветку, запушить её на remote , забрать с remote, внести изменения, запушить обратьно, забрать, смержить с первой версией и снова запушить обратно, поле чего удалить ветку на remote. А можно просто сделать ещё одни клон и локально мержить версии.
LB>Иначе получается, что из клона клона нужно пушить в оригинальный клон, а уже из него — в remote.
Что в этом сложного?
Здравствуйте, reson, Вы писали:
R>>>В меркуриале ничего не ломается и все замечательно пушится. Переходите на меркуриал! R>·>В git тоже ничего не ломается. Суть в том, что есть проблема разъезжания истории между клонами. В меркуриале эта проблема не решается, а заметается под коврик — неявно создаётся diverged история (кошмарик, называемый многоголовый бранч) и юзеру потом это придётся разгребать. git честно предупреждает о проблеме и юзеру можно выбрать как он хочет решить проблему. R>В меркуриале считается, что в рабочем каталоге могут быть файлы из любой ветки и есть отдельная команда, которая из ветки в рабочий каталог сохраняет изменения (hg update). Для распределенной системы версионного хранения ситуация с многими ветками и соответственно головами считается нормальной.
Не "нормальной", а одним из способов реализации. В git никаких многоголовых веток нет.
R>При желании можно их слить, это типовая операция.
Ветки получаются централизованными и это плохо масштабируется. Т.к. головы веток никак не отличимы — откуда и как они появились — в общем случае не различить. В git все ветки имеют уникальное описательное имя.
R>И поэтому нет необходимости вводить лишние сущности — bare и обычные репозитарии.
Я считаю что "многоголовость", "tip", "закладки" и прочие лишние сущности которых в mercurial пруд пруди — гораздо более лишние. Впрочем, bare repo в mercurial тоже есть.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
BFE>Получается, что в R2 сейчас лежат две версии: одна изменённая и одна не изменённая.
Да, одна версия будет в ветке mybranch, другая в ветке remotes/origin/mybranch.
BFE>2) вариант второй: BFE>Получается, что в R2 сейчас лежат две версии: одна изменённая и одна не изменённая.
Нет, будет одна версия, в ветке mybranch. Т.к. из R3 ты делаешь push origin XXX:mybranch
BFE>Вопрос: в чем для R2 принципиальная разница в результате?
Читай внимательно что я тебе пишу. Я тебе ответил уже три раза.
BFE>В репозитарии R2 так или иначе появляются изменения. Какая разница, откуда эти изменения там появились?
Разница в имени ветки, которая указывает на эти версии.
Ты наверное недопонимаешь суть веток в git, сравнивая их c mercurial. В mercurial ветки — более сложная структура их имена глобальны, что создаёт сложности для некоторых distributed сценариев. В git ветки исключительно локальны и позволяют поддерживать произвольные distributed сценарии.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, B0FEE664, Вы писали:
BFE>На это могут быть различные причины: BFE>например, может оказаться, что remote не доступен какое-то время, или BFE>допустим я внёс изменения в своей копии, но их ещё рано выкладывать в remote, при этом эти изменения мне нужны ещё для одной версии, которая будет разрабатываться параллельно с первой. Я, конечно, могу, завести ещё одну ветку, выложить эту ветку в remote и оттуда её забрать в другой локальный каталог. Т.е. создать ветку, запушить её на remote , забрать с remote, внести изменения, запушить обратьно, забрать, смержить с первой версией и снова запушить обратно, поле чего удалить ветку на remote. А можно просто сделать ещё одни клон и локально мержить версии.
В git для таких сценариев не требуется создавать клоны (как ты наверное привык в более примитивных vcs), для этого можно просто создавать локальные ветки — это работает быстрее, занимает меньше места и упрощает команды.
LB>>Иначе получается, что из клона клона нужно пушить в оригинальный клон, а уже из него — в remote. BFE>Что в этом сложного?
это сложнее, чем простые ветки. Клоны оправданы только в том случае, если тебе реально нужно иметь две рабочие копии одновременно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
BFE>>Получается, что в R2 сейчас лежат две версии: одна изменённая и одна не изменённая. ·>Да, одна версия будет в ветке mybranch, другая в ветке remotes/origin/mybranch.
BFE>>2) вариант второй: BFE>>Получается, что в R2 сейчас лежат две версии: одна изменённая и одна не изменённая. ·>Нет, будет одна версия, в ветке mybranch. Т.к. из R3 ты делаешь push origin XXX:mybranch
Почему сделано именно так?
BFE>>Вопрос: в чем для R2 принципиальная разница в результате? ·>Читай внимательно что я тебе пишу. Я тебе ответил уже три раза.
Три раза ответили и три раза не указали принципиальную причину. Раз раз вы так зациклились на ветках, то что мешает автоматически завести ещё одну ветку для данного случая? И что мешает при втором варианте положить изменения в ту же ветку, что и в первом варианте?
BFE>>В репозитарии R2 так или иначе появляются изменения. Какая разница, откуда эти изменения там появились? ·>Разница в имени ветки, которая указывает на эти версии.
Ну это же мелочи.
·>Ты наверное недопонимаешь суть веток в git, сравнивая их c mercurial. В mercurial ветки — более сложная структура их имена глобальны, что создаёт сложности для некоторых distributed сценариев.
Насколько я понимаю, ветки в git — это всего лишь надстройка над хранилищем слепков состояний. Поэтому, при желании, ветки можно перестраивать в любом порядке.
·>В git ветки исключительно локальны и позволяют поддерживать произвольные distributed сценарии.
В каком смысле "В git ветки исключительно локальны"? Что за ерунда? Я легко могу создать как ветку у себя, так и ветку на remote. Собственно, чтобы обойти указанное в первом сообщении темы ограничение git, я пушу изменение в клоне клона в клон задавая другую ветку, а потом мержу. Я не понимаю, почему автоматически так не сделано.
Здравствуйте, ·, Вы писали:
BFE>>На это могут быть различные причины: BFE>>например, может оказаться, что remote не доступен какое-то время, или BFE>>допустим я внёс изменения в своей копии, но их ещё рано выкладывать в remote, при этом эти изменения мне нужны ещё для одной версии, которая будет разрабатываться параллельно с первой. Я, конечно, могу, завести ещё одну ветку, выложить эту ветку в remote и оттуда её забрать в другой локальный каталог. Т.е. создать ветку, запушить её на remote , забрать с remote, внести изменения, запушить обратьно, забрать, смержить с первой версией и снова запушить обратно, поле чего удалить ветку на remote. А можно просто сделать ещё одни клон и локально мержить версии. ·>В git для таких сценариев не требуется создавать клоны (как ты наверное привык в более примитивных vcs), для этого можно просто создавать локальные ветки — это работает быстрее, занимает меньше места и упрощает команды.
Локальные ветки в данном случае будут только мешать.
Мало того, что после каждого переключения ветки нужно пересобирать бинарник, так ещё про карманные (git stash) изменения надо помнить.
LB>>>Иначе получается, что из клона клона нужно пушить в оригинальный клон, а уже из него — в remote. BFE>>Что в этом сложного? ·>это сложнее, чем простые ветки. Клоны оправданы только в том случае, если тебе реально нужно иметь две рабочие копии одновременно.
Ну так мне реально нужно иметь две рабочие копии одновременно.
Почему просто не сделать бранч в оригинальном клоне с сервера, провести в этом бранче необходимые изменения и (если нужно) смержить обратно в remote?