Здравствуйте, 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".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, 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.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, 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. Бред какой-то!
В меркуриале ничего не ломается и все замечательно пушится. Переходите на меркуриал!
BFE>·>В git для таких сценариев не требуется создавать клоны (как ты наверное привык в более примитивных vcs), для этого можно просто создавать локальные ветки — это работает быстрее, занимает меньше места и упрощает команды. BFE>Локальные ветки в данном случае будут только мешать. BFE>Мало того, что после каждого переключения ветки нужно пересобирать бинарник,
Ну это как-то далеко от современных практик. Если ветки отличаются немного, то инкрементальный билд работает быстро. Если различий много, то непонятно откуда такая разница окажется в одноимённой ветке.
BFE>так ещё про карманные (git stash) изменения надо помнить.
Эээ. А это зачем помнить?
BFE>>>Что в этом сложного? BFE>·>это сложнее, чем простые ветки. Клоны оправданы только в том случае, если тебе реально нужно иметь две рабочие копии одновременно. BFE>Ну так мне реально нужно иметь две рабочие копии одновременно.
До перехода на git это мне тоже неально было нужно, ибо в других vcs выбора особо нет. Потом вдруг внезапно выяснилось, то это нафиг не нужно в подавляющем большинстве случаев. Один более-менее реальный случай это когда я гонял исходники между виртуалками с разными осями.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Ты похоже никак принцип понять не можешь. Попробуй понять, что бранч это просто указатель. Вот и манипулируй ими.
BFE>>>fatal: this operation must be run in a work tree BFE>·>Если подумать, то станет ясно,что git fetch. BFE>И где же я должен делать git fetch?
Очевидно в этом bare репе.
BFE>·> Ведь даже я напоминал, что pull это fetch + merge, а в bare мержить негде. BFE>Вот именно, что мержить негде! Сейчас есть два bare репозитория с двумя разними версиями одного файла и мержить их негде.
Я же объяснил, что этот bare будет просто для перемещений бранчей. А значит мержи надо выполнять в других, B_clone в данном случае.
BFE>D:\Temp\A_clone>git st BFE>fatal: this operation must be run in a work tree
Хорошо, но уже лучше. У тебя в A_clone теперь есть master, который содержит изменение "commit from clone B" и FETCH_HEAD, который содержит "commit 2 from clone X". Вот эти два ref тебе и надо заиметь в B_clone для merge. Я тебе приведу один вариант как это можно сделать, а ты на досуге подумай о других возможностях.
В данном случае я бы сделал
D:\Temp\A_clone>git fetch origin master:master
// тут оно просто перезапишет master, ну и фиг с ним в данном случае.
D:\Temp\A_clone>cd ../B_clone
D:\Temp\B_clone>git pull
// тут у тебя в B_clone произойдёт merge, решаем конфликты, тестим, етс. Затем
D:\Temp\B_clone>git push
D:\Temp\B_clone>cd ../A_clone
D:\Temp\A_clone>git push
//Ура!
Магичесткий fetch origin master:master тебе понадобился потому что у тебя "ванильный" репо, общий случай, и ничего не настроено. В твоём случае удобнее будет иметь "git clone" с ключом "--mirror", тогда бы были бы установлены refspec и было бы удобнее. Врочем refspec ты можешь сконфигурить потом.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Потом перешёл в другой каталог и сделал клон клона:
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. Бред какой-то!
Здравствуйте, ·, Вы писали:
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".
Здравствуйте, ·, Вы писали:
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.
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>>Что в этом сложного? ·>это сложнее, чем простые ветки. Клоны оправданы только в том случае, если тебе реально нужно иметь две рабочие копии одновременно.
Ну так мне реально нужно иметь две рабочие копии одновременно.
Здравствуйте, 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 из клона-клона в клон.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Принципиально ветки — именованные _человеком_ ссылки на ревизии. Автоматически ветки создавать не стоит. Но если тебе очень хочется, то ты можешь простенький алиас написать.
Одним алиасом тут не обойтись. Нужно ещё, чтобы 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, но это будет усложнение на пустом месте без каких-либо объективных бенефитов, хотя субъективно может показаться удобнее.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
BFE>>Добавить в git новую функциональность — "не судьба"? ·>Во-первых, ты так и не описал собственно какую функциональность ты хочешь.
Хочу иметь возможность сделать push туда, откуда сделан clone.
·>Те сценарии которые ты описывал — элементарно ложатся на стандартные варианты использования.
Клон клона является стандартным вариантом использования?
·>Во-вторых, поизучай возможности расширения git, может тебе стоит создать пару тривиальных альясов и магия случится.
Что за "расширения git"?
·>В-третьих, это ж опенсорс, добавь сам.
Для этого надо убедится, что такое добавление уже не пытались сделать.
BFE>>>>Вот этот "делаешь pull" — где, откуда и куда? Напомню, что забрать в C из A не получится по условию задачи. BFE>>·>Да, неточно выразился. Вначале fetch, A в B, потом pull с разрешением конфликта из B в C. BFE>>Чего-то я не понимаю. Если на bare репозитории выполнить fetch, то pull из этого репозитория заберёт ту версию, что эта fetch обновила? А в какой момент эти две ветки сольются в одну на B? ·>Слитие произойдёт в C, в момент pull из B в C. На B никаких слитий не требуется делать, через него просто коммиты туда-сюда гоняются.
Каким образом через B пройдёт изменение от A, если на самом B уже лежит новая, но другая, пришедшая от D, версия?
·>Ты так и не рассказал что ты считаешь удобством. Более того, помимо зеркала тебе тут ещё несколько вариантов предлагали.
Предлагали обходные пути, а не решение.
·>Можно и не bare, но это будет усложнение на пустом месте без каких-либо объективных бенефитов, хотя субъективно может показаться удобнее.
Распределённая система не может быть простой.
Здравствуйте, B0FEE664, Вы писали:
BFE>·>Во-первых, ты так и не описал собственно какую функциональность ты хочешь. BFE>Хочу иметь возможность сделать push туда, откуда сделан clone.
Так делай. Это не работает только в случае, если у тебя тот же бранч что и текущий, т.к. это приводит к расползанию истории. Но ты можешь использовать другой бранч или updateInstead.
BFE>·>Те сценарии которые ты описывал — элементарно ложатся на стандартные варианты использования. BFE>Клон клона является стандартным вариантом использования?
Да.
BFE>·>Во-вторых, поизучай возможности расширения git, может тебе стоит создать пару тривиальных альясов и магия случится. BFE>Что за "расширения git"?
alias, например.
BFE>·>В-третьих, это ж опенсорс, добавь сам. BFE>Для этого надо убедится, что такое добавление уже не пытались сделать.
Ты так и не объяснил какое.
BFE>>>Чего-то я не понимаю. Если на bare репозитории выполнить fetch, то pull из этого репозитория заберёт ту версию, что эта fetch обновила? А в какой момент эти две ветки сольются в одну на B? BFE>·>Слитие произойдёт в C, в момент pull из B в C. На B никаких слитий не требуется делать, через него просто коммиты туда-сюда гоняются. BFE>Каким образом через B пройдёт изменение от A, если на самом B уже лежит новая, но другая, пришедшая от D, версия?
Просто в B перезапишет ветку. Делаешь все изменения и мержи в C,D, а B просто для синхронизации веток.
BFE>·>Ты так и не рассказал что ты считаешь удобством. Более того, помимо зеркала тебе тут ещё несколько вариантов предлагали. BFE>Предлагали обходные пути, а не решение.
Если задачи нет, то и решения не будет. А задачу ты так и не обозначил.
BFE>·>Можно и не bare, но это будет усложнение на пустом месте без каких-либо объективных бенефитов, хотя субъективно может показаться удобнее. BFE>Распределённая система не может быть простой.
Верно, и при этом git — по сравнению с другими dvcs — самая простая насколько это возможно, но не проще.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Lazy Bear, Вы писали:
LB>Здравствуйте, B0FEE664, Вы писали:
BFE>>Последний год всё глубже погружаюсь в дебри git.
BFE>>Допустим я взял с некого сервера исходники: BFE>>Потом перешёл в другой каталог и сделал клон клона:
LB>Но зачем?! Почему просто не сделать бранч в оригинальном клоне с сервера, провести в этом бранче необходимые изменения и (если нужно) смержить обратно в remote? LB>Иначе получается, что из клона клона нужно пушить в оригинальный клон, а уже из него — в remote.
Например, у клиента есть свой репозитарий. Есть фирма, которая пишет софт клиенту. Клонируем репозитарий клиента на сервер фирмы. Потом каждый разработчик клонирует этот репо себе и делает разработку, потом заливает на репо фирмы. Там все проверяется, ревьюится и финальная версия пушится ответственным человеком в репо клиента. Показывать внутреннюю кухню клиенту не хочется. Клиент тоже не хочет создавать отдельные аккаунты каждому разработчику. На клиента работает несколько фирм и у него есть своя разработка. Клиент сам хочет мерджить финальную версию фирмы к себе в мастер.
Здравствуйте, reson, Вы писали:
LB>>Но зачем?! Почему просто не сделать бранч в оригинальном клоне с сервера, провести в этом бранче необходимые изменения и (если нужно) смержить обратно в remote? LB>>Иначе получается, что из клона клона нужно пушить в оригинальный клон, а уже из него — в remote. R>Например, у клиента есть свой репозитарий. Есть фирма, которая пишет софт клиенту. Клонируем репозитарий клиента на сервер фирмы. Потом каждый разработчик клонирует этот репо себе и делает разработку, потом заливает на репо фирмы. Там все проверяется, ревьюится и финальная версия пушится ответственным человеком в репо клиента. Показывать внутреннюю кухню клиенту не хочется.
Для этого у ответственного человека будет два remote — один для репо клиента, другой для репо фирмы. Клоны клонов не нужны. Более того, репо фирмы скорее всего будет не просто репо, а репо-менеджер типа github/gitlab/bitbucket/whatever с CI и пулл-реквестами.
R>Клиент тоже не хочет создавать отдельные аккаунты каждому разработчику. На клиента работает несколько фирм и у него есть своя разработка. Клиент сам хочет мерджить финальную версию фирмы к себе в мастер.
Многие популярные репы на порядки сложее устроены, без проблем. linux.git всем миром колбасят, и хоть бы хны.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
BFE>>·>Во-первых, ты так и не описал собственно какую функциональность ты хочешь. BFE>>Хочу иметь возможность сделать push туда, откуда сделан clone. ·>Так делай. Это не работает только в случае, если у тебя тот же бранч что и текущий, т.к. это приводит к расползанию истории.
Расползание истории происходит каждый раз, когда двое редоктирую локально свои копии одного и того же файла. В этом нет ничего страшного.
·>Но ты можешь использовать другой бранч
Вот я и хочу, чтобы git по умолчанию использовал другой бранч, как он это делает для remote.
·>или updateInstead.
updateInstead не сработает, если на таргете изменены файлы в рабочей области.
BFE>>·>Те сценарии которые ты описывал — элементарно ложатся на стандартные варианты использования. BFE>>Клон клона является стандартным вариантом использования? ·>Да.
А чего ж в таком случае push нормально не проходит?
BFE>>·>Во-вторых, поизучай возможности расширения git, может тебе стоит создать пару тривиальных альясов и магия случится. BFE>>Что за "расширения git"? ·>alias, например.
Я уже обяснял, почему это не вариант.
BFE>>·>В-третьих, это ж опенсорс, добавь сам. BFE>>Для этого надо убедится, что такое добавление уже не пытались сделать. ·>Ты так и не объяснил какое.
Да что ж тут непонятного? Я хочу иметь возможность сделать push туда же откуда взял исходник.
·>Просто в B перезапишет ветку. Делаешь все изменения и мержи в C,D, а B просто для синхронизации веток.
Проверю на выходных, но тут что-то не так. Причём тут ветки? Ветка у нас одна.
·>Верно, и при этом git — по сравнению с другими dvcs — самая простая насколько это возможно, но не проще.
А вы все другие проверяли на их возможности? Что скажете про текущую версию Perforce и BitKeeper? Они сложнее?
Здравствуйте, B0FEE664, Вы писали: BFE>>>Хочу иметь возможность сделать push туда, откуда сделан clone. BFE>·>Так делай. Это не работает только в случае, если у тебя тот же бранч что и текущий, т.к. это приводит к расползанию истории. BFE>Расползание истории происходит каждый раз, когда двое редоктирую локально свои копии одного и того же файла. В этом нет ничего страшного.
Да. В чём тогда вопрос-то? BFE>·>Но ты можешь использовать другой бранч BFE>Вот я и хочу, чтобы git по умолчанию использовал другой бранч, как он это делает для remote.
Так я ж тебе объяснл как реализовать такую хотелку — добавить клон как remote. BFE>·>или updateInstead. BFE>updateInstead не сработает, если на таргете изменены файлы в рабочей области.
Ведь логично же. А что ты тогда хочешь? Если у тебя разъехались версии, то для надёжности тебе их надо как-то обозначить коммитами и бранчами, иначе сам же запутаешься что откуда. BFE>>>Клон клона является стандартным вариантом использования? BFE>·>Да. BFE>А чего ж в таком случае push нормально не проходит?
Я уже отвечал на этот вопрос раз 5. BFE>>>Что за "расширения git"? BFE>·>alias, например. BFE>Я уже обяснял, почему это не вариант.
Ты сказал что некий альяс должен о чём-то предупреждать. Но на вопрос о чём и зачем — ты ответить не смог. Так что если ты и объяснял, то не здесь. BFE>>>Для этого надо убедится, что такое добавление уже не пытались сделать. BFE>·>Ты так и не объяснил какое. BFE>Да что ж тут непонятного? Я хочу иметь возможность сделать push туда же откуда взял исходник.
Так делай. Просто при разъезжании истории делай брачи. Не надо пытаться всё свалить в кучу — это ненадёжный способ, легко приводит к ошибкам. git — надёжная система, прострелить ногу на пустом месте не даёт. BFE>·>Просто в B перезапишет ветку. Делаешь все изменения и мержи в C,D, а B просто для синхронизации веток. BFE>Проверю на выходных, но тут что-то не так. Причём тут ветки? Ветка у нас одна.
Ну раз история разъехалась, то веток, очевидно, несколько. В разных репах ветки разные, просто физически. BFE>·>Верно, и при этом git — по сравнению с другими dvcs — самая простая насколько это возможно, но не проще. BFE>А вы все другие проверяли на их возможности? Что скажете про текущую версию Perforce и BitKeeper? Они сложнее?
Про preforce я вообще мало хвалебных отзывов слышал — тормозилово и корпоративное глюкалово. А уж с т.з. простоты — тут уж по-моему очевидно.
А BitKeeper, напоминает софт как минимум тридцатилетней давности. Застряли в прошлом веке.
Это как — простота или они прикалываются?
(content conflict) ntpd/ntp_io.c>> <press enter>
---------------------------------------------------------------------------
File: ntpd/ntp_io.c
New work has been added locally and remotely and must be merged.
GCA: 1.403
Local: 1.404
Remote: 1.403.1.1
---------------------------------------------------------------------------
Commands are:
? - print this help
! - escape to an interactive shell
a - abort the patch, DISCARDING all merges
cl - clear the screen
C - commit the merged file
CC - commit the merged file with comments
d - diff the local file against the remote file
D - run side-by-side graphical difftool on local and remote
dl - diff the GCA vs. local file
dr - diff the GCA vs. remote file
dlm - automerge (if not yet merged) and diff the local file vs. merge file
drm - automerge (if not yet merged) and diff the remote file vs merge file
e - automerge (if not yet merged) and then edit the merged file
f - merge with graphical three-way filemerge
f2 - merge with graphical two-way filemerge
h - revision history of all changes
hl - revision history of the local changes
hr - revision history of the remote changes
H - show merge help in helptool
m - automerge the two files
p - graphical picture of the file history
q - immediately exit resolve
s - merge the two files using SCCS' algorithm
sd - side-by-side diff of the local file vs. the remote file
ul - use the local version of the file
ur - use the remote version of the file
v - view the merged file
vl - view the local file
vr - view the remote file
S - skip this file and resolve it later
x - explain the choices
Typical command sequence: 'e' 'C';
Difficult merges may be helped by 'p'.
А уж номерация версий сразу говорит о никакой децентрализованности.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
BFE>>·>Просто в B перезапишет ветку. Делаешь все изменения и мержи в C,D, а B просто для синхронизации веток. BFE>>Проверю на выходных, но тут что-то не так. Причём тут ветки? Ветка у нас одна. ·>Ну раз история разъехалась, то веток, очевидно, несколько. В разных репах ветки разные, просто физически.
Ну, что. Выходные. Проверил. Не работает.
Схема такая:
clone X < --- > исходный < --- > bare clone A < --- > clone B
репозиторий
Что делать, когда в исходном репозитории и в bare клоне лежат разные новые версии?
Порядок действий:
1) создаём репозиторий
D:\Temp\GitTests>git init --bare tst1.git
Initialized empty Git repository in D:/Temp/GitTests/tst1.git/
D:\Temp\GitTests>git config --global user.email "B0FEE664@gmail.com"
D:\Temp\GitTests>git config --global user.name "B0FEE664"
D:\Temp\GitTests>git config --global alias.st status
2) делаем клон X: D:\Temp\X_clone>git clone file://d:\Temp\GitTests\tst1.git .
Cloning into '.'...
warning: You appear to have cloned an empty repository.
6) на B вносим изменения в файл, затем делаем add/commit/push D:\Temp\B_clone>git add .
D:\Temp\B_clone>git commit -m "commit from clone B"
D:\Temp\B_clone>git st
D:\Temp\B_clone>git push
7) отправляем изменения из клона A в исходный репозиторий: D:\Temp\A_clone>git push
fatal: The current branch master has no upstream branch.
To push the current branch and set the remote as upstream, use
git push --set-upstream origin master
D:\Temp\A_clone>git push --set-upstream origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 269 bytes | 269.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To file://d:\Temp\GitTests\tst1.git
882feb6..2a5235e master -> master
Branch 'master' set up to track remote branch 'master' from 'origin'.
8) забираем изменения в клон X D:\Temp\X_clone>git pull
9) вновь на X вносим изменения в файл, затем делаем add/commit/push
D:\Temp\X_clone>git add .
D:\Temp\X_clone>git commit -m "commit 2 from clone X"
D:\Temp\X_clone>git push
10) вновь на B вносим изменения в файл, затем делаем add/commit/push D:\Temp\B_clone>git add .
D:\Temp\B_clone>git commit -m "commit 2 from clone B"
D:\Temp\B_clone>git st
D:\Temp\B_clone>git push
-------------------------------------------------------------------------
До этого момента всё работало,
но теперь в основном репозитории и в его bare клоне A лежат разные версии.
Пытаюсь их синхронизировать:
D:\Temp\A_clone>git push
To file://d:\Temp\GitTests\tst1.git
! [rejected] master -> master (fetch first)
error: failed to push some refs to 'file://d:\Temp\GitTests\tst1.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
D:\Temp\A_clone>git pull
fatal: this operation must be run in a work tree
D:\Temp\A_clone>git pull --rebase
fatal: this operation must be run in a work tree
BFE>D:\Temp\A_clone>git pull BFE>fatal: this operation must be run in a work tree
Если подумать, то станет ясно,что git fetch. Ведь даже я напоминал, что pull это fetch + merge, а в bare мержить негде.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали: BFE>>D:\Temp\A_clone>git pull BFE>>fatal: this operation must be run in a work tree ·>Если подумать, то станет ясно,что git fetch.
И где же я должен делать git fetch? ·> Ведь даже я напоминал, что pull это fetch + merge, а в bare мержить негде.
Вот именно, что мержить негде! Сейчас есть два bare репозитория с двумя разними версиями одного файла и мержить их негде.
Скрытый текст
D:\Temp\A_clone>git st
fatal: this operation must be run in a work tree
D:\Temp\A_clone>git status
fatal: this operation must be run in a work tree
D:\Temp\A_clone>git push
To file://d:\Temp\GitTests\tst1.git
! [rejected] master -> master (non-fast-forward)
error: failed to push some refs to 'file://d:\Temp\GitTests\tst1.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
D:\Temp\A_clone>git pull
fatal: this operation must be run in a work tree
Здравствуйте, ·, Вы писали:
·>Ты похоже никак принцип понять не можешь. Попробуй понять, что бранч это просто указатель. Вот и манипулируй ими.
Да нет, это вы не понимаете, что использование бранчей в данной конфигурации равносильно использованию костылей. Я же показал сценарий, где до некоторых пор всё идёт хорошо, всё работает и вдруг "внезапно" система оказывается в патовой ситуации из которой без использования веток никак не выйти. Нормальные системы так не работают.
BFE>>>>fatal: this operation must be run in a work tree BFE>>·>Если подумать, то станет ясно,что git fetch. BFE>>И где же я должен делать git fetch? ·>Очевидно в этом bare репе.
Почему очевидно? Зачем в bare делать fetch, если смержить всё равно в баре нельзя?
BFE>>·> Ведь даже я напоминал, что pull это fetch + merge, а в bare мержить негде. BFE>>Вот именно, что мержить негде! Сейчас есть два bare репозитория с двумя разними версиями одного файла и мержить их негде. ·>Я же объяснил, что этот bare будет просто для перемещений бранчей. А значит мержи надо выполнять в других, B_clone в данном случае.
А вам не кажется это несколько странным? Вот если бы A_clone был нормальным репозиторием, то прямо в нём и можно было бы делать merge без всяких извращений.
Почему мержи надо делать в B_clone? Какой в этом сакральный смысл?
·> BFE>>D:\Temp\A_clone>git st BFE>>fatal: this operation must be run in a work tree ·> ·>
во-во. теперь и вы понимаете, что это не нормально.
·> BFE>>D:\Temp\A_clone>git fetch BFE>>remote: Counting objects: 3, done. BFE>>remote: Total 3 (delta 0), reused 0 (delta 0) BFE>>Unpacking objects: 100% (3/3), done. BFE>>From file://d:\Temp\GitTests\tst1 BFE>> * branch master -> FETCH_HEAD ·> ·>Хорошо, но уже лучше. У тебя в A_clone теперь есть master, который содержит изменение "commit from clone B" и FETCH_HEAD, который содержит "commit 2 from clone X". Вот эти два ref тебе и надо заиметь в B_clone для merge. Я тебе приведу один вариант как это можно сделать, а ты на досуге подумай о других возможностях.
А я уже давно подумал. Этот merge должен проходить именно там, где появился конфликт, а именно на в A_clone.
·>В данном случае я бы сделал ·> ·>D:\Temp\A_clone>git fetch origin master:master ·>// тут оно просто перезапишет master, ну и фиг с ним в данном случае.
это с данном случае, а в общем случае B_clone может не существовать, но на A_clone могут уже лежать смерженные изменения с B_clone и ещё десятка других репозиториев. Мы их сейчас затрём и всю работу по мержу начнём с начала. "Очень удобно!"
·>D:\Temp\A_clone>cd ../B_clone ·>D:\Temp\B_clone>git pull ·>// тут у тебя в B_clone произойдёт merge, решаем конфликты, тестим, етс. Затем ·>D:\Temp\B_clone>git push ·>D:\Temp\B_clone>cd ../A_clone ·>D:\Temp\A_clone>git push ·>//Ура! ·>
Увы, это не нормально, когда одну и ту же работу, приходится делать по 10 раз.
·>Магичесткий fetch origin master:master тебе понадобился потому что у тебя "ванильный" репо, общий случай, и ничего не настроено. В твоём случае удобнее будет иметь "git clone" с ключом "--mirror", тогда бы были бы установлены refspec и было бы удобнее. Врочем refspec ты можешь сконфигурить потом.
Т.е. предлагается вручную настраивать то, что должно работать из коробки. При этом настроить так, чтобы всё работало как надо всё равно не получится, так как придётся вручную следить за изменениями в ветках и не забывать их мержить. А знаете почему? Потому, что git не является распределённой системой контроля версий, хотя могла бы.
Здравствуйте, B0FEE664, Вы писали:
BFE>·>Ты похоже никак принцип понять не можешь. Попробуй понять, что бранч это просто указатель. Вот и манипулируй ими. BFE>Да нет, это вы не понимаете, что использование бранчей в данной конфигурации равносильно использованию костылей. Я же показал сценарий, где до некоторых пор всё идёт хорошо, всё работает и вдруг "внезапно" система оказывается в патовой ситуации из которой без использования веток никак не выйти. Нормальные системы так не работают.
Ты показал, лишь своё упрямое невежество.
BFE>>>И где же я должен делать git fetch? BFE>·>Очевидно в этом bare репе. BFE>Почему очевидно?
Потому что по данному тобой условию задачи только в этом репе ты имеешь доступ туда откуда надо вытянуть новые изменения.
BFE>Зачем в bare делать fetch, если смержить всё равно в баре нельзя?
Fetch и merge совершенно независимые операции. А значит твой вопрос бесмысленный.
BFE>>>Вот именно, что мержить негде! Сейчас есть два bare репозитория с двумя разними версиями одного файла и мержить их негде. BFE>·>Я же объяснил, что этот bare будет просто для перемещений бранчей. А значит мержи надо выполнять в других, B_clone в данном случае. BFE>А вам не кажется это несколько странным? Вот если бы A_clone был нормальным репозиторием, то прямо в нём и можно было бы делать merge без всяких извращений.
Если ты очень хочешь, то сделай его non-bare репом, такое решение я тебе тоже объяснял. Я просто считаю, что в твоём сценарии наиболее простой подход — именно такой.
BFE>Почему мержи надо делать в B_clone? Какой в этом сакральный смысл?
Потому что это с практической т.з. более удобно. Как правило merge сам по себе не главное. После merge обычно надо хотя бы поглядеть на результаты из IDE, прогнать компиляцию, тесты и т.п. Проект скорее всего будет уже открытым в B_clone (в "конечном" репе) и готовым на всё, а в зеркале через которое ты просто гоняешь данные туда-сюда, ведь зеркало просто для обеспечения доступа.
BFE>·> BFE>во-во. теперь и вы понимаете, что это не нормально.
Конечно ненормально. Я это давно сказал, но к врачу ты отказался идти.
BFE>·>Хорошо, но уже лучше. У тебя в A_clone теперь есть master, который содержит изменение "commit from clone B" и FETCH_HEAD, который содержит "commit 2 from clone X". Вот эти два ref тебе и надо заиметь в B_clone для merge. Я тебе приведу один вариант как это можно сделать, а ты на досуге подумай о других возможностях. BFE>А я уже давно подумал. Этот merge должен проходить именно там, где появился конфликт, а именно на в A_clone.
Конфликт — результат merge. Так что пока ты merge не выполнишь, конфликтов никаких нет.
BFE>это с данном случае, а в общем случае B_clone может не существовать,
Создай C_clone и сделай там.
BFE>но на A_clone могут уже лежать смерженные изменения с B_clone и ещё десятка других репозиториев. Мы их сейчас затрём и всю работу по мержу начнём с начала. "Очень удобно!"
Преобразуй bare repo в non-bare и сделай там.
BFE>Увы, это не нормально, когда одну и ту же работу, приходится делать по 10 раз.
Какую работу? Делать "fetch"? Ты это никак не избежишь. Ты сам сказал, что прямого доступа нет, а значит придётся прыгать. Впрочем, на практике проблемы с прямым доступом довольно редки. В худшем случае ssh туннель и понеслось.
BFE>·>Магичесткий fetch origin master:master тебе понадобился потому что у тебя "ванильный" репо, общий случай, и ничего не настроено. В твоём случае удобнее будет иметь "git clone" с ключом "--mirror", тогда бы были бы установлены refspec и было бы удобнее. Врочем refspec ты можешь сконфигурить потом. BFE>Т.е. предлагается вручную настраивать то, что должно работать из коробки. При этом настроить так, чтобы всё работало как надо всё равно не получится, так как придётся вручную следить за изменениями в ветках и не забывать их мержить.
У тебя довольно редкий и специфичный сценарий. Притом он даже уже есть из коробки с ключом --mirror. Но тебе пофиг, тебе главное доказать своё невежество.
BFE>А знаете почему? Потому, что git не является распределённой системой контроля версий, хотя могла бы.
А какой же он является?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
BFE>>А знаете почему? Потому, что git не является распределённой системой контроля версий, хотя могла бы. ·>А какой же он является?
BFE>По умолчанию защита от forced push, да, не включается. Если это нужно, ставится receive.denyNonFastForwards=true в центральной репе.
На заборе тоже пишут. Можешь у него уточнить что он имел в виду.
Хинт: если я сделаю "denyNonFastForwards=true" в трёх репах, станет ли git трижды централизованной СКВ?
BFE>Тут важно, что "в центральной репе". Т.о. git — это централизованная система контроля версий.
У тебя проблемы с логикой. Даже если эту цитату воспринимать буквально и без контекста, то самый строгий вывод можно сделать лишь о том, что git может использоваться как централизованная СКВ.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
BFE>>По умолчанию защита от forced push, да, не включается. Если это нужно, ставится receive.denyNonFastForwards=true в центральной репе.
·>На заборе тоже пишут. Можешь у него уточнить что он имел в виду.
А ещё на заборе пишут, что git — distributed version control system. Вот я и пытаюсь понять, что имеется ввиду.
·>Хинт: если я сделаю "denyNonFastForwards=true" в трёх репах, станет ли git трижды централизованной СКВ?
Тут важно, что "в центральной репе", а не опции настройки.
BFE>>Тут важно, что "в центральной репе". Т.о. git — это централизованная система контроля версий. ·>У тебя проблемы с логикой. Даже если эту цитату воспринимать буквально и без контекста, то самый строгий вывод можно сделать лишь о том, что git может использоваться как централизованная СКВ.
git может использоваться как централизованная СКВ. Собственно никак иначе (без специальных ухищрений) она не может использоваться.
Здравствуйте, B0FEE664, Вы писали:
BFE>·>На заборе тоже пишут. Можешь у него уточнить что он имел в виду. BFE>А ещё на заборе пишут, что git — distributed version control system. Вот я и пытаюсь понять, что имеется ввиду.
Вот он там ниже
и пояснил, что под центральной имеется в виду "общая репа", т.е. репа, которая используется более чем одним юзером. Очевидно, что таких реп может быть несколько.
BFE>·>Хинт: если я сделаю "denyNonFastForwards=true" в трёх репах, станет ли git трижды централизованной СКВ? BFE>Тут важно, что "в центральной репе", а не опции настройки.
Нет, тут важно понимать смысл написанного.
BFE>>>Тут важно, что "в центральной репе". Т.о. git — это централизованная система контроля версий. BFE>·>У тебя проблемы с логикой. Даже если эту цитату воспринимать буквально и без контекста, то самый строгий вывод можно сделать лишь о том, что git может использоваться как централизованная СКВ. BFE>git может использоваться как централизованная СКВ.
Верно.
BFE>Собственно никак иначе она не может использоваться.
Это твои фантазии.
BFE> (без специальных ухищрений)
А это демагогия.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Почему просто не сделать бранч в оригинальном клоне с сервера, провести в этом бранче необходимые изменения и (если нужно) смержить обратно в remote?
