Здравствуйте, ·, Вы писали:
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 репе.
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 ты можешь сконфигурить потом.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ты похоже никак принцип понять не можешь. Попробуй понять, что бранч это просто указатель. Вот и манипулируй ими.
Да нет, это вы не понимаете, что использование бранчей в данной конфигурации равносильно использованию костылей. Я же показал сценарий, где до некоторых пор всё идёт хорошо, всё работает и вдруг "внезапно" система оказывается в патовой ситуации из которой без использования веток никак не выйти. Нормальные системы так не работают.
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?
