вопрос по git (мержить ветки)

git rebase --onto

>И тут получается 1 merge commit.

merge commit один, но вся история остается, если, конечно, не делать git merge --squash

И еще, есть удаленный репозиторий. В локально сделал merge. Вижу этот коммит. Но push на сервер нифига не могу. Everything up-to-date. Хотя на сервере merge коммита нету.

Не должно такого быть. Точно правильные ветки смежил? Никто кроме тебя не мог сделать тот же самый мерж?
Еще, посмотри diff HEAD..origin/master

rebase старой ветки на новую, и потом merge в новую ветку из «старой»

а ты точно нужную бранчу на сервер пушишь?

>rebase старой ветки на новую, и потом merge в новую ветку из «старой»

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

>а ты точно нужную бранчу на сервер пушишь?

ну да, текущий бранч пытаюсь git push git://remote.git remote-branch_name

>Не должно такого быть. Точно правильные ветки смежил? Никто кроме тебя не мог сделать тот же самый мерж?

Еще, посмотри diff HEAD..origin/master

Так грубо говоря как можно по другому смержить - не понятно. Сделал checkout в локальный бранч, потом туда мерж. git log показывает что все правильно. Потом пытаюсь запушить в другой репозитарий в бранч с другим именем. git push туда пушит но без мержа.

>непойму зачер ребейз делать если комиты и так сверху

«Сверху» они в твоей бранче, которая основана на 2.6.18. А в ситуации

ветка A основанная на 2.6.18 с кучей патчей сверху и теперь предположим что есть ветка B основанная на 2.6.39

между ветками существенная разница, поэтому сначала надо (1) перетянуть в ветку А все изменения с 2.6.18 по 2.6.39, (2) наложить поверх этого свои патчи, (3) разрулить возможные конфликты и (4) проверить, что всё работает, и потом сделать мерж из А в B. Пункты 1-3 выполняются как раз в ребейзе.

Естественно, можно сделать экспериментальную ветку на основе А и проводить манипуляции в ней (чтобы сохранить изменения для 2.6.18).

Потом пытаюсь запушить в другой репозитарий в бранч с другим именем. git push туда пушит но без мержа.

Ман читай.

man git-push

git-push [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v | --verbose] [<repository> <refspec>...]

<refspec>
The canonical format of a <refspec> parameter is ?<src>:<dst>; that is, an optional plus , followed by the source ref, followed by a colon :, followed by the destination ref. The <src> side can be an arbitrary «SHA1 expression» that can be used as an argument to git-cat-file -t. E.g. master~4 (push four parents before the current master head).

The local ref that matches <src> is used to fast forward the remote ref that matches <dst>. If the optional plus + is used, the remote ref is updated even if it does not result in a fast forward update.

Note: If no explicit refspec is found, (that is neither on the command line nor in any Push line of the corresponding remotes file---see below), then «matching» heads are pushed: for every head that exists on the local side, the remote side is updated if a head of the same name already exists on the remote side.

Хм, ребейз надо изучить, то есть получатется как то так:
git rebase A2.6.18
git rebase A2.6.18 B2.6.39
git checkout B2.6.39
git merge A2.6.18
git push git://remote branch_name

Попозже попробую скажу если получится.

git rebase A2.6.18

git rebase A2.6.18 B2.6.39

git checkout A2.6.18

git rebase B2.6.39

В остальном похоже на правду

yoghurt! Ты супер 100 лет тебе жизни! Я вчера весь день на эту муть потратил..

Хм что-то странно. смержил до 2.6.32.44 теперь хочу туда еще коммиты от 2.4.32.45 так-же засунуть.

git checkout KORG32_v2.6.32.45
git checkout MY_v2.6.32.44
git rebase KORG32_v2.6.32.45


Git начинает накладывать кучу патчей и я получаю кучу реджектов, хотя различая 44 и 45 веток в 10 комитах от силы, которые надо набрасать сверху.

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

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

Вот это кстати очень хорошая мысль. Спасибо.