[Andoird][Kernel]работа с git ом

Смотреть diff -uNr 2.6.29 2.6.29-LG, и курить, что изменилось к .35?

для начала немного покурить git, например отсюда http://progit.org/book/ru/.

дальше найти fork-commit и сделать rebase с устранением конфликтов.

задача полностью решаемая, но можно погрязнуть в трех местах:

• очень маловероятно, но LG-шники могли отстрипать метаданные git'а.
• они-же могли много нагадить (а-ля indent).
• может быть много конфликтов.

если повезет, минимально примерно так:

git clone git://android-repo-url
git remote add lg git://lg-repo-url
git fetch lg

git checkout -b my origin/master
git merge lg/master
либо
git checkout -b my lg/master
git rebase origin/master

не совсем так. код LG тает тарболом

есть дифф от оригинала и есть место (коммит) откуда оригинал изменился.

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

при rebase куча странных конфликтов как и при mergе при том что при rebase странные конфликты, которые не связаны даже с кодом

tarball это облом, большой облом.

Тогда два варианта:

• как предложили смотреть diff. Но! нужно найти исходный git-repo, с которого был форк lg. Далее залить исходники lg в отдельную векту. Написав скрипт можно передрать все коммиты и найти наиболее подходящие к точки ветвления. Дальше merge или rebase.
• другой вариант diff в лоб как предлагали.

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

Но я все-таки думаю у LG где-то должен быть readonly git репозиторий, иначе это просто долбо#$^м. Как вариант где-то в tarball есть хвосты по которым можно найти точку fork от андро или еще чего-нибудь.

точку ответвления нашел. вопрос как убить кучу конфликтов

Вопрос в том, какие именно конфликты

когда я пробовал делать rebase часть патчей слитела, хотя после просмотра фалов конфликт был не понятен, гит написал что патч конфликует с HEAD хотя измения которые он приносил были абсолютно законными и причина конфликта не понятна. В случае rebase git дает возможность пропустить патч, просто после такого я не уверен в работоспособности кода

Не совсем понятно, что ты имеешь в виду когда говоришь про «странные конфликты» и «изменения которые он приносил были абсолютно законными и причина конфликта не понятна».

Могу предположить что ситуация примерно такая:

• в коде от LG есть мелкие бессмысленные правки, например висячие пробелы и т.д.;
• после fork'а в репозиторий LG вливались (через merge) отдельные правки из mainstream;
• в mainstream есть коммиты с правками вида «туда-сюда»;
• возможно, LG-шники заюзали чью-то лажу типа «rebase after push», а когда спохватились не осилили re-merge и забили на pull-слияния (в fork'ах такая ситуация - не редкость);

В итоге ты получаешь наблюдаемую кучу конфликтов. Если уже нашел точку fork'а, то теперь чуть легче. Но отсутствие (как я понял) полной истории со стороны LG порождает главную проблему - ты видишь все правки скопом, без разделения на коммиты. Поэтому крайне сложно разобраться, что с чем связано.

Что делать, думаю сам догадался - заняться любовью, и тут есть варианты:

• с LG-маинтейнерами, чтобы дали доступ к git-истории (т.е. всем метаданным);
• с конфликтами в коде, т.е. вникнуть и пофиксить;
• с подругой

Решать тебе ;-)

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

А как вы собираетесь бинарные драйвера от .29 к .35 прикрутить? Или lg исходники дает? o_0

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

можно ли заставит git вносить изменения по коммитам что бы можно было отслеживать появление конфликтов?

> можно ли заставит git вносить изменения по коммитам что бы можно было отслеживать появление конфликтов?

Я не совсем понимаю что ты хочешь сказать, либо ты что-то не правильно понял/сделал.

man git-rebase

man git-merge

man git-filter-branch

порядок важен.