Форк из Github в Bitbucket

Так DVCS же. Разницы нет, откуда pull'ить, куда push'ить.

Просто создаешь два remote, из оригинального репозитория забираешь код, мержишь, делаешь какие-то изменения, и засылаешь в свой. Выглядит как-то так:

$ git remote add origin {bitbucket repo}
$ git remote add upstream {github repo}
$ git fetch upstream
$ git merge upstream/master
$ git push

Вау! Спасибо вам за ответы. Допёр теперь))

Кстати, ты уже разобрался со своим push -f?

Да с ним-то всё понятно. Вот как без push -f разбираться часто совсем непонятно. Особенно после hg git. Вот совсем свежий пример:

$ git push origin master
error: src refspec master matches more than one.
error: failed to push some refs to 'git@github.com:Balancer/bors-ext.git'

$ git tag
master

$ git branch
* master

Непонятно, каких «refspec master matches more than one» он имеет в виду.

Ну, нагуглил я, что надо локальный тег удалить (зачем?).

$ git tag -d master
Deleted tag 'master' (was ddff33a)

А дальше снова начинается старая фигня, из-за которой в своё время данные и потерял:

$ git push origin master
To git@github.com:Balancer/bors-ext.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:Balancer/bors-ext.git'
подсказка: Updates were rejected because the tip of your current branch is behind
подсказка: its remote counterpart. Integrate the remote changes (e.g.
подсказка: 'git pull ...') before pushing again.
подсказка: See the 'Note about fast-forwards' in 'git push --help' for details.

Одна беда, это bare:

$ git pull
fatal: /usr/lib/git-core/git-pull cannot be used without a working tree.

git fetch ни разу не помогает:

$ git fetch
From github.com:Balancer/bors-ext
 * branch            HEAD       -> FETCH_HEAD

$ git push origin master
To git@github.com:Balancer/bors-ext.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'git@github.com:Balancer/bors-ext.git'
подсказка: Updates were rejected because the tip of your current branch is behind
подсказка: its remote counterpart. Integrate the remote changes (e.g.
подсказка: 'git pull ...') before pushing again.
подсказка: See the 'Note about fast-forwards' in 'git push --help' for details.

Ну и дальше скипнуто традиционное, что с Mercurial за годы работы без всякого обучения и подсказок такого никогда не бывало...

Вот, такая же фигня: не получается запушить на github

Только рецепты типа hg status не помогают, т.к. у меня bare.

http://blogs.perl.org/users/mr_muskrat/2010/10/remove-a-git-tag-from-github-w... ?

Непонятно, каких «refspec master matches more than one» он имеет в виду.

что непонятно-то? когда ты говоришь master это может быть как тег, так и бранч. git в данном случае не может определить, что ты имел в виду (хотя это и противоречит gitrevisions(7), но может на всякий случай от дурачков подстраховались) и предлагает тебе указать более конкретно что ты хочешь, например heads/master

Одна беда, это bare:

конечно, как ты собрался делать merge или rebase без working tree?

git fetch ни разу не помогает:

и не должен.

способ решения проблемы: пойди в не-bare репозиторий, сделай в нем merge и тогда уже делай push.

Ну, нагуглил я, что надо локальный тег удалить (зачем?).

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

пойди в не-bare репозиторий, сделай в нем merge и тогда уже делай push

Офигеть. git merge вывалил мне десятка два конфликтов модификаций, при том, что я непосредственно с ним даже и не работал, только перепушивал результат hg-git'а. А в hg за последний год конфликты модификаций (не смотря на то, что я работаю с десятка разных мест и правки вношу асинхронно, не всегда синхронизируя) были единичные. И их не было с сентября, когда я пушил последний раз в git.

Короче, поскольку такую кашу с merge разбирать себе дороже, опять запушил с -f. Похоже, это единственно вменяемое применение git в моей практике. Вести основной репозиторий в mercurial, а в git тупо делать w/o копию :)

ты распространитель идиотизма в этом мире, вместо того чтобы прочитать документацию и сделать правильно

Я просто не вижу смысла изучать совершенно невменяемую документацию, которую итак все раскритиковали и которую и без того мало кто понимает, в то время, как есть параллельная система, в которой годами всё прекрасно работает вообще без чтения документации. Можете считать меня идиотом, но я предпочитаю секс в уютной кровата, а не в гаммаке, стоя и с надетым противогазом. Хотя последнее и развивает акробатические навыки.

Офигеть. git merge вывалил мне десятка два конфликтов модификаций, при том, что я непосредственно с ним даже и не работал, только перепушивал результат hg-git'а.

ну так это тебе hg-git запорол историю, спроси у его разрабов, для чего они так делают.

откуда у тебя вообще конфликты и не fast-forward апдейты, если ты не коммитишь в git напрямую? одно из предположений - ты hg-git-ом пропушил изменения, которые потом сам же и изменил?

Я просто не вижу смысла изучать совершенно невменяемую документацию

в том-то и дело, что там нечего «изучать», все описание работы git умещается на одной-двух страницах, а дальше достаточно читать сообщения на экране и изредка заглядывать в маны.

например в данном случае чтобы понять что такое src refspec достаточно прочитать один абзац из git push, который описывает что такое вообще refspec.

одно из предположений - ты hg-git-ом пропушил изменения, которые потом сам же и изменил?

Как это «изменил изменения»? Я, как раз, сторонних подхода «никаких правок истории». Я просто делаю регулярные pull/modify/commit/push из разных мест. Иногда забываю сделать pull, при push получаю предупреждение о появлении второго head, делаю merge (безконфликтный!) и снова push. И так — год за годом. В mercurial проблем нет. Зато после сделанного однажды push'а в git (копия репозитория совершенно идентичная меркурийному) через два месяца при аналогичном же push накопленных изменений получаю множественные конфликты.

Да, я не сказал ещё, там 2/3 «конфликтов» типа «добавилась строчка». Очевидно, что строчка добавлялась. Или даже (1/3 случаев) менялась. Но Mercurial мержит такие изменения автоматом. Между любыми ревизиями. Мне приходилось так сводить накопившиеся расхождения многомесячной давности. А тут — я не понял, что мешает git'у смержить добавление одной строчки в файл?

Например:

file ..\*\\.(tpl|TPL)$ Smarty\sTemplate\sFile
include smarty.syntax

file ..\*\\.(md|MD)$ Markdown
include markdown.syntax
<<<<<<< HEAD

file \.go$ GoLang
include go.syntax
=======
>>>>>>> 51a102105c7c231b3fa47907973773b8a131b8ce

в том-то и дело, что там нечего «изучать», все описание работы git умещается на одной-двух страницах

Значит, я такой недалёкий, а git настолько сложнее mercurial'а в использовании. Ибо, как писал, по mercurial я не читал вообще ничего и использую его успешно много лет, а вот по git, как раз, читал массу how-to, не говоря уже про гуглёж десятков страниц и множество споров на ЛОРе, но так пользоваться за пределами простейшего юзкейса «pull/modify/commit/push» и не могу.

а дальше достаточно читать сообщения на экране и изредка заглядывать в маны.

Читал многократно, даже сегодня (чего, опять же, никогда не делал в Mercurial — там хватает help в командной строке) — как разруливать такие конфликты — непонятно.

например в данном случае чтобы понять что такое src refspec достаточно прочитать один абзац из git push

Читал. Но как это позволит решить мои проблемы там не увидел.

Зато после сделанного однажды push'а в git (копия репозитория совершенно идентичная меркурийному) через два месяца при аналогичном же push накопленных изменений получаю множественные конфликты.

ты получаешь non-fast-forward-update, т.е. кто-то (видимо ты при помощи hg-git) переписал историю.

Да, я не сказал ещё, там 2/3 «конфликтов» типа «добавилась строчка».

есть разница между мержем двух разошедшихся несколько месяцев назад head-ов (с изменением истории в процессе) и несколькими мержами, в каждом случае бесконфликтными.

а вот по git, как раз, читал массу how-to, не говоря уже про гуглёж десятков страниц и множество споров на ЛОРе, но так пользоваться за пределами простейшего юзкейса «pull/modify/commit/push» и не могу.

а и не надо никаких howto, нужно просто сесть и понять, как он внутри устроен, дальше все очевидно.

Читал многократно, даже сегодня (чего, опять же, никогда не делал в Mercurial — там хватает help в командной строке) — как разруливать такие конфликты — непонятно.

какие такие? созданные невменяемыми создателями hg-git?

нужно просто сесть и понять, как он внутри устроен, дальше все очевидно

Ну, вот в этом и разница. В Mercurial, чтобы эффективно им пользоваться, понимать внутреннее устройство не нужно. Можно просто брать и начинать пользоваться. Да ещё и данные потерять случайно или по ошибке вписав ключик не получится :)

какие такие? созданные невменяемыми создателями hg-git?

Да какая разница, как конфликт возник. В Mercurial я могу спокойно собрать в одном репозитории сколь угодно конфликтные изменения, даже если конфликт пошёл с самого начала и произвольно смержить ревизии голов. При этом я всегда смогу поднять любое старое значение в графе изменений, восстановить его, перемержить, переключиться на него. Всё очень просто, визуально отображаемо, доходчиво и понятно. Мне доводилось сводить очень старые и запущенные конфликты — даже вопроса «как это сделать» не возникало.

А тут — непонятно, с какой стороны подходить даже. Вне зависимости от того, кто конфликты породил.

ты получаешь non-fast-forward-update, т.е. кто-то (видимо ты при помощи hg-git) переписал историю.

Вот, видимо, тут и проблема. В Mercurial история не переписывается. И поэтому можно пушить сколь угодно сложную конфигурацию. Можно хоть залить с одной машины конфликтное дерево и разобрать конфликт потом на другой. А в git можно влезть в историю и получить такое.

отсюда и вывод - не влезай.

отсюда и вывод - не влезай

Так я сам, ручками и нарочно и не влезаю. Оно как-то само получается :) И, ладно бы ещё через hg-git, но я сталкивался уже с подобным и просто при активной работе с git из разных мест при отсутствии своевременных пушей и/или при перекрёстных пушах минуя центральный репозиторий.

не знаю твоей ситуации. единственное, что я всегда делаю перед пушем - `git pull -r origin master`

Ну, вот в этом и разница. В Mercurial, чтобы эффективно им пользоваться, понимать внутреннее устройство не нужно. Можно просто брать и начинать пользоваться. Да ещё и данные потерять случайно или по ошибке вписав ключик не получится :)

а я уверен, что для синхронизации между двумя VCS нужно хорошо понимать внутреннее устройство обоих. просто пользоваться - может быть и не надо.

Да какая разница, как конфликт возник. В Mercurial я могу спокойно собрать в одном репозитории сколь угодно конфликтные изменения, даже если конфликт пошёл с самого начала и произвольно смержить ревизии голов. При этом я всегда смогу поднять любое старое значение в графе изменений, восстановить его, перемержить, переключиться на него. Всё очень просто, визуально отображаемо, доходчиво и понятно. Мне доводилось сводить очень старые и запущенные конфликты — даже вопроса «как это сделать» не возникало.

а я могу то же самое сделать в git, сюрприз?

Вот, видимо, тут и проблема. В Mercurial история не переписывается.

так в том-то и дело, что видимо, история таки переписывается, это с точки зрения hg она не изменилась, а git каких-то вольностей, допустимых для hg не прощает.

Можно хоть залить с одной машины конфликтное дерево и разобрать конфликт потом на другой.

в git тоже можно, просто там для этого отличный от hg workflow - пушить надо не в master, а в другой бранч.

А в git можно влезть в историю и получить такое.

мы уже разбирали, что в hg тоже можно влезть в историю, просто это сделать чуть сложнее.

у тебя кстати не осталось все-таки старой версии репозитория? я бы тебе может подсказал, из-за чего история разошлась.

позволю себе похулиганить :)

fixed:

Форк из Github в ненужно

у тебя кстати не осталось все-таки старой версии репозитория?

Можно будет повторить, я представляю, как оно воспроизводится. Только позже, в ближайшие дни работы дофига, сегодня лимит времени на эксперименты исчерпал :)

я, кстати, дождался пока ты свой git реп обновишь и перепишешь историю

for i in c2172960a60895225a155844610a89926140dacb e5aed04a3c3991b24f441b418abb2181b687244f ; do git cat-file -p $i ; done
tree d7175beca6b5bb18ba65de2d132c1532a2dbb61d
parent 0f0cfc69ccba51dabb0fb5cf54a756e6accf1a47
author Balancer <balancer@balancer.ru> 1314006687 +0400
committer Balancer <balancer@balancer.ru> 1314006687 +0400

Доработка разметки, введение разметки Trac-like ({ { { … } } } ), доработка документации по свойствам объектов.
tree d7175beca6b5bb18ba65de2d132c1532a2dbb61d
parent 0f0cfc69ccba51dabb0fb5cf54a756e6accf1a47
author Balancer <balancer@balancer.ru> 1314006687 +0400
committer Balancer <balancer@balancer.ru> 1314006687 +0400
HG:rename data/fs/_bors/doc/objects/properties.bbh:data/fs/_bors/doc/objects/properties.htsu

Доработка разметки, введение разметки Trac-like ({ { { … } } } ), доработка документации по свойствам объектов.

реконструкция событий такая: ты сливал hg репозиторий в git при помощи hg-git, потом hg-git обновился и начал при синхронизации писать в git больше информации. Больше информации выливается в переписывание истории и конфликты. Теперь ты либо сделал ещё одну синхронизацию с машины с необновленным hg-git, либо разрабы эту фичу отключили.

Я сейчас на hg-git забил и делаю конверсию хитрее — делаю импорт из hg в git через fast-export, а потом уже git штатно пушу на GitHub. Изменения пока отрабатываются корректно.