Git Upstream Manager - дополнительный режим работы Git, позволяющий легко вести ветки разработки со своими патчами и обновлять их с апстрим веток, при этом ведя общую общую историю изменений и поддерживая патчи всегда в актуальном состоянии согласно состоянию апстрим. В данной баге буду записывать этапы разработки проекта.
Занимался изучением существующих инструментов работы с Git для Python. Рассмотрел GitPython, pygit2, Dilwich. Все инструменты сейчас находятся в разработке и подходят не полностью. Далее продолжу изучение инструментов и займусь первоначальным дизайном проекта.
Возможно, стоит рассмотреть вариант постройки поверх существующих утилит, используя в качестве связки только sh. Хотя python, конечно, вариант, но хочется максимально избежать лишних зависимостей. Но для нас целеполагающее, конечно — это скорость разработки.
Кстати, GitPython мы уже используем в одном проекте — git.eter:/projects/wine/test-robot.git Там активная работа с патчами, мержи, ветки... Всё работает. Может быть при прочих равных использовать его? Чтобы уж не в каждом проекте своя библиотека...
Остановился на GitPython. Начал реализацию: http://git.etersoft.ru/people/piastry/packages/?p=git-um.git;a=summary
Работал над данной задачей. Добавил возврат к превоначальному состоянию и поменял вывод с трэйса Python на вывод комманд Git. Что сейчас работает: 1. Основной функционал по обработки веток при применении изменений из апстрим. 2. Возможность возобновление работы после разрешения кофликтов слияния. 3. Возможность полного прерывания операции - возврат на первоначальное состояние.
Работал над задачей. Изменения: 1) возможность конфигурирования веток, 2) сохранение состояний ведётся без создания дополнительных веток, 3) коммиты из аптрим применяются в рабочую ветку с актуальными сообщениями, 4) рефакторинг кода.
Работал над задачей. Изменения: 1) команда инициализация, 2) автоматическое обновление rebased ветки 3) изменены названия команд и добавлено их описанию, 4) применён парсер argsparse, 5) добавлена возможность пропустить патч в rebase процессе, 6) удалённую ветку можно теперь задавать в конфигурационном файле, 7) рефакторинг кода.
Работал над задачей: 1) Исправил ошибку в использовании только удалённой ветки по умолчанию 2) Перешёл на использование GitPython-0.3.0 (с 0.1.6), которая является текущей в Sisyphus. 3) Провёл тестирование на реальном репозитории cifs-2.6.
Работал над задачей: 1) Ознакомился с системой пакетирования для Python. 2) Создал новую иерархию репозитория. 3) Перенёс переменные бранчей из глобального пространства в класс GitUpstream. 4) Добавил setup.py и правила для gear. 5) Небольшой рефакторинг кода. Выпустил релиз 0.1-alt1: http://git.etersoft.ru/people/piastry/packages/?p=git-um.git;a=summary
Собрал на git.eter ([#1631] DONE git-um.git=0.1-alt1) и сделал анонс в рассылке devel@.
Выделилась задача на следующий релиз 0.2: 1) Команда create должна сама создавать указанные ветки (либо брать имена по умолчанию).
(В ответ на comment #11) > Выделилась задача на следующий релиз 0.2: > 1) Команда create должна сама создавать указанные ветки (либо брать имена по > умолчанию). 2) Надо найти замену GitCommandError.stdout.
> master - наша копия ветки origin/master > patches - ветка с нашими патчами наверху > dev - текущая ветка разработки А чем patches от dev отличается? И где хранится история? Попробовал потестировать: $ git clone git://source.winehq.org/git/wine.git wine-um $ git reset --hard wine-1.3.31 $ git branch patches $ git branch dev Прикладываем наш патч в dev-ветке: $ git checkout dev $ git am 0001-Add-support-of-native-Windows-drivers-for-USB-tokens.txt $ git-um create --remote origin/master --upstream master --rebased patches --current dev .git-un-config missing, using default branch names... Тут опечатка: .git-uN-config ? Сохраняем наш патч в patches: $ git-um update HEAD^ HEAD Теперь пробуем обновиться от 1.3.31 до текущего апстрима: $ git-um pull .......... Довольно долго работает, надо сказать... Через какое-то время упало: merge commit 8e62e823d6a41f40d1b50c5a77083290f525bb0c patching file dlls/mmdevapi/tests/capture.c patching file dlls/mmdevapi/tests/render.c merge commit 507d92905174ccef96a33a806bfc383874ff7dcf Traceback (most recent call last): File "/usr/bin/git-um", line 72, in <module> main() File "/usr/bin/git-um", line 51, in main GitUpstream().pull() File "/usr/lib/python2.6/site-packages/gitupstream/gitupstream.py", line 53, in pull self._process_commits() File "/usr/lib/python2.6/site-packages/gitupstream/gitupstream.py", line 163, in _process_commits print(e.stdout) AttributeError: 'GitCommandError' object has no attribute 'stdout' $ git branch * (no branch) dev master patches git-um pull берёт обновления из origin/master или из master? Если из origin/master, то, ИМХО, это не всегда удобно. Хочется, чтобы была возможность обновиться до какого-то релиза апстрима, а не до самого последнего коммита.
(В ответ на comment #13) > > master - наша копия ветки origin/master > > patches - ветка с нашими патчами наверху > > dev - текущая ветка разработки > А чем patches от dev отличается? И где хранится история? История хранится последовательно в dev, в ветке patches наши патчи всегда лежат сверху апстрим. > > > Попробовал потестировать: Спасибо! > > $ git clone git://source.winehq.org/git/wine.git wine-um > $ git reset --hard wine-1.3.31 > $ git branch patches > $ git branch dev > > Прикладываем наш патч в dev-ветке: > $ git checkout dev > $ git am 0001-Add-support-of-native-Windows-drivers-for-USB-tokens.txt > > $ git-um create --remote origin/master --upstream master --rebased patches > --current dev > .git-un-config missing, using default branch names... > > Тут опечатка: .git-uN-config ? Да, конечно. > > Сохраняем наш патч в patches: > $ git-um update HEAD^ HEAD > > Теперь пробуем обновиться от 1.3.31 до текущего апстрима: > $ git-um pull > .......... > Довольно долго работает, надо сказать... Потому что оно каждый раз делает rebase с очередным коммитом из апстрим - чтобы держать актуальной ветку patches и не потерять историю в ветке dev. > > Через какое-то время упало: > merge commit 8e62e823d6a41f40d1b50c5a77083290f525bb0c > patching file dlls/mmdevapi/tests/capture.c > patching file dlls/mmdevapi/tests/render.c > merge commit 507d92905174ccef96a33a806bfc383874ff7dcf > Traceback (most recent call last): > File "/usr/bin/git-um", line 72, in <module> > main() > File "/usr/bin/git-um", line 51, in main > GitUpstream().pull() > File "/usr/lib/python2.6/site-packages/gitupstream/gitupstream.py", line 53, > in pull > self._process_commits() > File "/usr/lib/python2.6/site-packages/gitupstream/gitupstream.py", line 163, > in _process_commits > print(e.stdout) > AttributeError: 'GitCommandError' object has no attribute 'stdout' Сам только сегодня обнаружил эту багу, появившуюся от переезда с GitPython 0.1.6 на 0.3.0. Тут видимо конфликт мержинга произошёл: можно посмотреть grep "<<<" * -R. После того, как исправлю багу, будет выводится сообщение из-за чего произошла проблема. Пока же можно не обращать на это внимание. > > $ git branch > * (no branch) > dev > master > patches > > git-um pull берёт обновления из origin/master или из master? > Если из origin/master, то, ИМХО, это не всегда удобно. Хочется, чтобы была > возможность обновиться до какого-то релиза апстрима, а не до самого последнего > коммита. Обновления берутся из ветки --remote (в нашем случае origin/master), которая была указана в git-um create команде и складываются в ветку --upstream (тоже указанную git-um create - нашем случае master) . Можно добавить аргумент к команде git-um pull чтобы можно было указать с какой удалённой веткой мержиться в этот раз. И использовать значение из конфига, если этот аргумент не указан. Так же стоит добавить строчку в .gitignore: .git-um-*
(В ответ на comment #14) > > Пока же можно не обращать на это внимание. Нужно найти проблемный файл, исправить, сделать git add файл и продолжить процесс дальше: git-um pull --continue
Сделал git add, что-то оно не хочет продолжать: [amorozov@atlant wine-um]$ git diff | cat [amorozov@atlant wine-um]$ git-um pull --continue .git-un-config missing, using default branch names... Traceback (most recent call last): File "/usr/bin/git-um", line 72, in <module> main() File "/usr/bin/git-um", line 45, in main GitUpstream().continue_pull('--continue') File "/usr/lib/python2.6/site-packages/gitupstream/gitupstream.py", line 64, in continue_pull self._load_state() File "/usr/lib/python2.6/site-packages/gitupstream/gitupstream.py", line 233, in _load_state self._saved_branches[self._upstream] = f.readline().split()[0] AttributeError: 'GitUpstream' object has no attribute '_upstream' > История хранится последовательно в dev, в ветке patches наши патчи всегда лежат > сверху апстрим. Правильно ли я понимаю, что коммит в dev - это дифф между двумя состояниями ветки patches (до ребэйза поверх нового коммита и после), сохранённый под именем этого коммита? Посмотрел git log dev. Как-то меня смущает то, что я там получаюсь автором всех патчей из апстрима. ИМХО, выкидывать оригинального автора неправильно. > Можно добавить аргумент к команде git-um pull чтобы можно было указать с какой > удалённой веткой мержиться в этот раз. И использовать значение из конфига, если > этот аргумент не указан. Может быть, лучше мержиться с master? А для обновления master до нужного коммита сделать какую-то отдельную команду? А то иначе непонятно, зачем вообще этот master нужен, если то, что в нём хранится, не влияет на мерж?
(В ответ на comment #16) > Сделал git add, что-то оно не хочет продолжать: > [amorozov@atlant wine-um]$ git diff | cat > [amorozov@atlant wine-um]$ git-um pull --continue > .git-un-config missing, using default branch names... главная проблема тут. Видимо, .git-um-config включился в ветку dev и после смены бранчей естественно пропал. Проблема в том, что после наложения патча приходится делать git add -A, который подцепляет его, если не указать правило в .gitignore. Я думаю, стоит сделать так, чтобы create сам добавлял нужное правило. Но возникает такая проблема: 1 случай) : .gitignore не был добавлен в репозиторий ранее. Тогда мы посто создаём его и добавляем нужны правила. 2 случай): .gitignore был добавлен в репозиторий. Тогда нам нужно не только добавить нужное правило, но ещё и закоммитить изменения - сделать дополнительный коммит в ветке dev. Потом его нужно перенести в patches, чтобы поддерживать инвариант (git diff patches dev == 0). Чтобы не рассматривать отдельна два случая можно всегда следовать второму. При этом, когда мы будем генерировать патчи из ветки patches нам просто не надо учитывать первый коммит после master. > Traceback (most recent call last): > File "/usr/bin/git-um", line 72, in <module> > main() > File "/usr/bin/git-um", line 45, in main > GitUpstream().continue_pull('--continue') > File "/usr/lib/python2.6/site-packages/gitupstream/gitupstream.py", line 64, > in continue_pull > self._load_state() > File "/usr/lib/python2.6/site-packages/gitupstream/gitupstream.py", line 233, > in _load_state > self._saved_branches[self._upstream] = f.readline().split()[0] > AttributeError: 'GitUpstream' object has no attribute '_upstream' Ага, бага если не находит конфиг файл - исправлю. > > > История хранится последовательно в dev, в ветке patches наши патчи всегда лежат > > сверху апстрим. > Правильно ли я понимаю, что коммит в dev - это дифф между двумя состояниями > ветки patches (до ребэйза поверх нового коммита и после), сохранённый под > именем этого коммита? Да. > > Посмотрел git log dev. Как-то меня смущает то, что я там получаюсь автором всех > патчей из апстрима. ИМХО, выкидывать оригинального автора неправильно. Исправлю. > > > Можно добавить аргумент к команде git-um pull чтобы можно было указать с какой > > удалённой веткой мержиться в этот раз. И использовать значение из конфига, если > > этот аргумент не указан. > Может быть, лучше мержиться с master? А для обновления master до нужного > коммита сделать какую-то отдельную команду? А то иначе непонятно, зачем вообще > этот master нужен, если то, что в нём хранится, не влияет на мерж? master нужен вот зачем: чтобы понять какие коммиты из апстрима мы уже обработали и какие нет. То есть, каждый раз мы получаем список новых коммитов и накладываем их последовательно в master, patches и dev.
Задачи на следующий релиз 0.2: 1) Команда create должна сама создавать указанные ветки (либо брать имена по умолчанию). Так же она должна править .gitignore файл для ветки разработки. 2) Надо найти замену GitCommandError.stdout. Сделать вывод pull удобным для восприятия и информативным. 3) Коммиты из апстрим под оригинальным авторством. 4) Аргумент к pull, чтобы вручную указывать, из какой ветки тянуть изменения. 5) Инициализация веток по умолчанию в случае неполноты или отсутствия .git-um-config.
Нашёл альтернативу для GitCommandError.stdout. Теперь пробрасываю гит команде rebase временный файл для вывода stdout, и при случае ошибки слияния, вывожу вывод гит команды из файла на экран.
(В ответ на comment #18) > Задачи на следующий релиз 0.2: > > 1) Команда create должна сама создавать указанные ветки (либо брать имена по > умолчанию). Так же она должна править .gitignore файл для ветки разработки. Сделано. > > 2) Надо найти замену GitCommandError.stdout. Сделать вывод pull удобным для > восприятия и информативным. Сделано тут http://bugs.etersoft.ru/show_bug.cgi?id=7690#c19. > > 3) Коммиты из апстрим под оригинальным авторством. Сделано. > > 4) Аргумент к pull, чтобы вручную указывать, из какой ветки тянуть изменения. Сделано. Теперь pull принимает аргумент --branch NAME (в случае начала слияния). > > 5) Инициализация веток по умолчанию в случае неполноты или отсутствия > .git-um-config. Сделано. Далее планирую заняться более тщательным тестированием и подготовкой к выпуску 0.2.
Работал над задачей. 1. Перенёс конфигурационные файлы в .git/. 2. Переименовал в gitum (без дефиса). 3. Добавил команду remove. 4. Поправил вывод сообщений. 5. Исправил некоторые баги и неточности. Протестировал и собрал версию 0.2-alt1 ([#1880] DONE git-um.git=0.2-alt1).
Поправил небольшую неточность, собрал 0.2-alt2 ([#1885] DONE git-um.git=0.2-alt2). Сделал следующие изменения (войдут в следующий релиз - 0.3-alt1): 1. Лог не выбрасывается библиотекой по умолчанию. gitum утилита выставляет параметр with_log=True. 2. Добавлен тест на основной функционал. 3. Исправлена работа библиотеки в режиме пере переиспользования GitUpstream объекта.
Посмотрел. В первом приближении вроде всё ОК. Есть несколько предложений: 1. При работе git pull в строках merge commit 97b7bb2bab60342a90ab3392f7b42b0f72bdec20 хорошо бы выводить ещё какой нибудь счётчик, что это n-й коммит из m. А то оно долго работает, хорошо бы представлять, сколько ещё ждать. 2. Можно ли сделать, чтобы gitum update работал без аргументов? Например, искал коммит с эквивалентным head-у другой ветки содержимым и обновлял от него. 3. Можно ли сделать, чтобы gitum update мог обновлять не только rebased-ветку на основе current-ветки, но и наоборот: current-ветку на основе rebased-ветки? Вроде бы в любом случае это просто прикладывание патчей из одной ветки к другой.
Подумал тут ещё. В чём цель наличия наших патчей сверху? В том, что мы можем какой-то патч легко убрать или изменить. Но при работе с текущим gitum не очень понятно, как это делать. Убрать легко, если у нас один независимый (от других наших патчей) патч. Тогда можно просто откатить его в rebased-ветке и приложить получившийся коммит к current-ветке. Если же у нас, например, два патча, и нам надо убрать первый, то нам надо откатить два патча, а затем приложить второй, отредактировав его. И приложить два отката и отредактированный патч из rebased-ветки к current-ветке. Случай с изменением патча похоже выглядит. Вроде бы всё ОК, но мне не очень нравится, что в rebased-ветке будут множественные откаты и прикладывания одного и того же патча. Всё-таки цель - получить минимальный и понятный набор патчей. Кроме того, текущий gitum не позволяет нам получить этот понятный набор патчей сверху для какой-то старой версии.
(В ответ на comment #23) > Посмотрел. В первом приближении вроде всё ОК. > Есть несколько предложений: > > 1. При работе git pull в строках > merge commit 97b7bb2bab60342a90ab3392f7b42b0f72bdec20 > хорошо бы выводить ещё какой нибудь счётчик, что это n-й коммит из m. А то оно > долго работает, хорошо бы представлять, сколько ещё ждать. Да. > > 2. Можно ли сделать, чтобы gitum update работал без аргументов? Например, искал > коммит с эквивалентным head-у другой ветки содержимым и обновлял от него. Тут можно просто сохранять топ ветки dev в state-файле после pull и при update мержить в rebased разницу между ними. > > 3. Можно ли сделать, чтобы gitum update мог обновлять не только rebased-ветку > на основе current-ветки, но и наоборот: current-ветку на основе rebased-ветки? > Вроде бы в любом случае это просто прикладывание патчей из одной ветки к > другой. Если мы меняем ветку, rebase, то мы не добавляем туда новых патчей. Мы только можем изменить там существующий набор патчей (отредактировать или удалить какой-то патч). После этого у нас получается новая ветка rebase. Далее мы делаем diff со старой и накладываем в dev и коммитим. Этот функционал нужно добавлять отдельной командой - например, editpatches.
(В ответ на comment #24) > Подумал тут ещё. В чём цель наличия наших патчей сверху? В том, что мы можем > какой-то патч легко убрать или изменить. Но при работе с текущим gitum не очень > понятно, как это делать. Описал выше. Такой функционал просто ещё не добавлен. > > Убрать легко, если у нас один независимый (от других наших патчей) патч. Тогда > можно просто откатить его в rebased-ветке и приложить получившийся коммит к > current-ветке. Если же у нас, например, два патча, и нам надо убрать первый, то > нам надо откатить два патча, а затем приложить второй, отредактировав его. И > приложить два отката и отредактированный патч из rebased-ветки к current-ветке. > Случай с изменением патча похоже выглядит. Вроде бы всё ОК, но мне не очень > нравится, что в rebased-ветке будут множественные откаты и прикладывания одного > и того же патча. Всё-таки цель - получить минимальный и понятный набор патчей. > > Кроме того, текущий gitum не позволяет нам получить этот понятный набор патчей > сверху для какой-то старой версии. Используя подход, описанные выше, у нас получается минимальный набор патчей. Получается что делает команда editpatches: 1) перед выполнением git diff rebased dev == 0 2) запускается интерактивный rebase на ветке rebased. 3) после того, как мы отредактировали наши патчи, и rebase завершился успешно, получается diff между новым rebased и dev. 4) этот diff накладывается на dev и делается коммит с введённым нами сообщением. 5) в результате на выходе: git diff rebased dev == 0 rebased с обновлёнными патчами наверху dev - с одним коммитом, исправляющим (удаляющим) существующий патч. Чтобы история в ветке dev была как можно более актуальной, то в момент интерактивного rebase нужно менять (удалять) только один патч. Соответственно, чтобы изменить (удалить) несколько патчей, нужно сделать несколько раз gitum editpatches (может быть даже стоит её назвать editpatch).
Работал над задачей: 1) Реализовал счётчик [cur/all] для текущего обрабатываемого коммита из апстрим ветки. 2) Реализовал команду editpatch: а) editpatch - открывает интерактивный rebase б) editpatch --continue/--abort/--skip - передаёт данные команды rebase a) editpatch --commit делает коммит на основе diff между предыдущей версии ветки с патчами и новой версии.
Работал над задачей. 1) Изменил интерфейс команды update - теперь можно пользоваться двумя способами: а) gitum update -n N, б) gitum update HEAD~N:HEAD, где N - количество коммитов, которые нужно перенести из ветки разработки в ветку с патчами. 2) Добавил код для проверки актуальности состояния перед pull, update, editpatch. 3) Поправил код. 4) Провёл тестирование. 5) Собрал версию 0.3-alt1: [#1893] DONE gitum.git=0.3-alt1 и слелал сообщение в рассылку.
> 5) Собрал версию 0.3-alt1: [#1893] DONE gitum.git=0.3-alt1 и слелал сообщение в > рассылку. Тестировал на Wine репозитории - успешно. Так же заметил, что подход, используемый в нашей реализации, не работает для апстрим-репозиториев, которые имеют не непрерывную историю (то есть содержат коммиты вида "Merge .. into .."). Примером таких репозиториев может служить репозиторий ядра Linux. Обратными примерами (непрерывная история) являются: Wine, Samba. Для работы с репозиториями первого вида, можно мержить только коммиты начинающиеся с "Merge ..." + все остальные коммиты сверху. История конечно потеряется, но скорость значительно увеличится. Здесь вопрос остаётся открытым.
> б) gitum update HEAD~N:HEAD, Не работает: $ gitum update HEAD~1:HEAD usage: gitum [-h] {pull,update,create,remove,editpatch} ... gitum: error: unrecognized arguments: HEAD~1:HEAD После editpatch переходим в rebased-ветку: $ git branch * dev master patches $ gitum editpatch Successfully rebased and updated refs/heads/patches. $ git branch dev master * patches Было бы лучше вернуться обратно в ту ветку, в которой мы были. Если вписать edit для одного из коммитов, то выведет такое: Stopped at 7403672... Add support of native Windows drivers for USB tokens. You can amend the commit now, with git commit --amend Once you are satisfied with your changes, run git rebase --continue Было бы неплохо, чтобы писало gitum editpatch вместо git rebase, если это возможно сделать. Ещё такой вопрос. Если кто-то допустит ошибку при редактировании rebased-ветки, то как потом откатить его изменения? Особенно если это заметили не сразу.
Спасибо за тестирование! (В ответ на comment #30) > > б) gitum update HEAD~N:HEAD, > Не работает: > $ gitum update HEAD~1:HEAD > usage: gitum [-h] {pull,update,create,remove,editpatch} ... > gitum: error: unrecognized arguments: HEAD~1:HEAD Надо так: gitum update --range HEAD~1:HEAD (Всегда можно посмотреть справку к команде с помощью gitum COMMAND -h) > > После editpatch переходим в rebased-ветку: > $ git branch > * dev > master > patches > $ gitum editpatch > Successfully rebased and updated refs/heads/patches. > $ git branch > dev > master > * patches > Было бы лучше вернуться обратно в ту ветку, в которой мы были. Чтобы закончить процесс editpatch, нужно дать комманду gitum editpatch --commit // сделает коммит в dev, согласно изменениям из editpatch. и вернёмся в ветку dev. > > Если вписать edit для одного из коммитов, то выведет такое: > Stopped at 7403672... Add support of native Windows drivers for USB tokens. > You can amend the commit now, with > > git commit --amend > > Once you are satisfied with your changes, run > > git rebase --continue > > Было бы неплохо, чтобы писало gitum editpatch вместо git rebase, если это > возможно сделать. Да, точно - надо поправить. > > Ещё такой вопрос. Если кто-то допустит ошибку при редактировании rebased-ветки, > то как потом откатить его изменения? Особенно если это заметили не сразу. Пока не сделан gitum editpatch --commit, всегда можно сделать gitum editpatch --abort, который вернёт всё как было.
> > Ещё такой вопрос. Если кто-то допустит ошибку при редактировании rebased-ветки, > > то как потом откатить его изменения? Особенно если это заметили не сразу. > > Пока не сделан gitum editpatch --commit, всегда можно сделать gitum editpatch > --abort, который вернёт всё как было. А если уже сделан? Например, кто-то объединил пару десятков патчей в один. Потом решили, что это плохо. Как всё вернуть назад без кучи ручной работы? В общем, было бы неплохо как-то сохранять предыдущие состояния rebased-ветки.
(В ответ на comment #32) > > А если уже сделан? Например, кто-то объединил пару десятков патчей в один. > Потом решили, что это плохо. Как всё вернуть назад без кучи ручной работы? > В общем, было бы неплохо как-то сохранять предыдущие состояния rebased-ветки. В случае, если --commit уже сделан, то на данный момент никак. Если требуется возвращать назад состояние ветки rebase, то нужно возвращать назад и состояние веткок master и current. Так же если есть вероятность, что в последнем действии могут напортачить, то и есть вероятность напортачить в двух последних действиях и т.д. Возможно, стоит хранить всю историю изменений? Возникает вопрос как хранить. 1. Завести ветку states (форк любого места master), куда добавить файл __state__, где написать: master_id rebased_id current_id и в нужный момент обновлять данный файл и делать коммит в ветку states. Если потребуется вернуть какое состояние - просто вытаскиваем нужное состояние из ветки и делаем reset --hard каждой ветки на соответствующий коммит айди. Достоинства: - файл не разрастается; - можно легко переносить с места на место - коммитить в удалённый бранч. Недостатки: - присутствие посторонней ветки в репозитории; - проект потенциально может содержать файл с таким же названием. 2. Завести файл в .git/ где хранить данные о ветке (как и в предыдущем пункте + дату/описание). В нужный момент добавлять в данный файл состояние. Достоинства: - нет посторонней ветки; - ислючается возможность совпадения имён. Недостатки: - файл с историей разрастается; - сложность в перенесении с места на место.
> 1. Завести ветку states (форк любого места master), куда добавить файл > __state__, где написать: .................... > - проект потенциально может содержать файл с таким же названием. Можно завести спец. ветку только с этим файлом. Тут ещё такой вопрос. Не получится ли так, что в результате какого-нибудь git gc старые коммиты rebased_id, упоминающиеся в файле __state__ будут вычищены, ведь на них никто не ссылается? > 2. Завести файл в .git/ где хранить данные о ветке (как и в предыдущем пункте + > дату/описание). В нужный момент добавлять в данный файл состояние. .................... > - сложность в перенесении с места на место. Я так понимаю, нельзя будет сделать git push. Если так, то это не подходит.
Я, когда обсуждал с Виталиком подобную систему, предлагал делать ветку, в которой бы хранился файл с номером коммита апстрима и набор патчей поверх в виде текстовых файлов. В такой системе rebased- и current-ветки можно было автоматически генерировать из этой ветки с патчами.
(В ответ на comment #34) > > 1. Завести ветку states (форк любого места master), куда добавить файл > > __state__, где написать: > .................... > > - проект потенциально может содержать файл с таким же названием. > > Можно завести спец. ветку только с этим файлом. Да, точно. > > Тут ещё такой вопрос. Не получится ли так, что в результате какого-нибудь git > gc старые коммиты rebased_id, упоминающиеся в файле __state__ будут вычищены, > ведь на них никто не ссылается? Получится. > > > 2. Завести файл в .git/ где хранить данные о ветке (как и в предыдущем пункте + > > дату/описание). В нужный момент добавлять в данный файл состояние. > .................... > > - сложность в перенесении с места на место. > > Я так понимаю, нельзя будет сделать git push. Если так, то это не подходит. Ок.
(В ответ на comment #35) > Я, когда обсуждал с Виталиком подобную систему, предлагал делать ветку, в > которой бы хранился файл с номером коммита апстрима и набор патчей поверх в > виде текстовых файлов. В такой системе rebased- и current-ветки можно было > автоматически генерировать из этой ветки с патчами. Чтобы легко генерировать ветку с патчами, нужно ещё сохранять коммит из current (вывод git format-path -1) после каждого обновления этого бранча. То есть на данный момент я вижу такой алгоритм действий: 1) Произошёл gitum update, gitum editpatch --commit или gitum pull (diff rebased current == "") 2) rm -rf *.patch; git format-patch UPSTREAM.HEAD.id..REBASED.HEAD.id 3) mv *.patch /tmp/tempgitumdir 4) git format-patch CURRENT.HEAD.id^..CURRENT.HEAD.id 5) mv *.patch /tmp/tempgitumdir/current_patch_ 6) git checkout patches_branch (ветка с патчами) 7) git rm *.patch; mv /tmp/tempgitumgir/*.patch ./ 8) git add *.patch 9) mv /tmp/tempgitumdir/current_patch_ ./ 10) git add current_patch_ 11) UPSTREAM.HEAD.id -> state 12) git commit -m CURRENT.HEAD.message После этого у нас ветка patches_branch содержит последние актуальные патчи, коммит из апстрим, на который они накладываются и изменение для current ветки (для её восстановления).
К сожалению, при создании баги утерялась первоначальная формулировка задачи (см. также URL): В репозитории создаётся несколько веток 1. upstream (неизменённая) 2. rebase (где наши патчи всегда сверху) 3. history - она же непрерывная (куда отражается в виде коммита каждое изменение ветки 2) 4. patches - ветка с нашими патчами Схема такая 1. в ветке 1 появляется новый коммит 2. делаем rebase ветки 2, чтобы добавить новый коммит, оставив наши патчи сверху 3. делаем diff между новым состоянием ветки 2 и предыдущим, получаем коммит, который добавляем в ветку 3 Ветка 4, по сути, просто хранит результат git format-patch для наших коммитов в ветке 2 Суть в том, что ветка 3 получается непрерывной, там сохраняется история, последовательно добавляются коммиты. Её можно использовать для сборки пакетов и для публикации Получившийся коммит в ветке 3 будет не копией коммита из апстрима и лишь его подобием. При этом возможно использовать описание оригинального коммита, ведь подобный коммит будет вносить те же изменения.
> 1) Произошёл gitum update, gitum editpatch --commit или gitum pull (diff > rebased current == "") > > 2) rm -rf *.patch; git format-patch UPSTREAM.HEAD.id..REBASED.HEAD.id > > 3) mv *.patch /tmp/tempgitumdir > > 4) git format-patch CURRENT.HEAD.id^..CURRENT.HEAD.id > > 5) mv *.patch /tmp/tempgitumdir/current_patch_ > > 6) git checkout patches_branch (ветка с патчами) > > 7) git rm *.patch; mv /tmp/tempgitumgir/*.patch ./ > > 8) git add *.patch > > 9) mv /tmp/tempgitumdir/current_patch_ ./ > > 10) git add current_patch_ > > 11) UPSTREAM.HEAD.id -> state > > 12) git commit -m CURRENT.HEAD.message > Реализовал данный функционал. Далее нужно добавить генерацию веток upstream, rebased и current по данной ветке для обеспечения переносимости репозитория путём перенесения лишь данной ветки.
> Реализовал данный функционал. Далее нужно добавить генерацию веток upstream, > rebased и current по данной ветке для обеспечения переносимости репозитория > путём перенесения лишь данной ветки. Добавил генерацию веток по ветке с патчами. Теперь для восстановления любого состояния репозитория достаточно вынуть нужный коммит из данной ветки и сделать gitum restore - ветки создадутся заново в нужном состоянии (с копиями коммитов, которые были на тот момент).
Добавил исключения в вызовы модуля gitupstream, что позволит корректно использовать как библиотеку. Поправил код, исправил некоторые неточности. Написал письмо в рассылку со своим видением требуемого функционала.
Работал над задачей: 1) Переместил конфигурационный файл в отедельную ветку gitum-config. 2) Переименовал команду pull в merge (что больше соответсвует действительности). 3) Добавил возможность работы с удалённым gitum репозиторием: а) clone б) pull - локальные коммиты остаются наверху (копии). в) push в удалённый gitum репозиторий. 4) Исправлен баг несохранения ветки с патчами при merge.
1) Добавил возможность работы не только из корневой папки git репозитория. 2) Переписал существующий тест, добавил новый на проверку удалённой работы. 3) Переписал логику команды restore - теперь имена веток берутся из конфигурационного файла + команда принимает идентификатор коммита для восстановления. 4) Поработал над стилем кода, поправил некоторые ошибки.
Поправил команду push (ветка rebased заливается только через --force, поскольку постоянно обновляется через rebase), добавил возможность указать git-remote для команды pull, поправил код restore. Провёл тесты и выпустил gitum-0.4.1-alt1: [#2085] DONE gitum.git=0.4.1-alt1.
Конфигурационный файл, похоже, неправильно заполняется: $ gitum create --remote origin/master --upstream master --rebased rebased --patches patches --current dev $ git show gitum-config:.gitum-config | cat remote = origin/master current = dev upstream = master rebased = patches patches = patches
Сделал страничку на Wiki: http://wiki.etersoft.ru/GitUM?v=142w. По поводу create: [piastry@euclid gitum]$ gitum create --remote origin/master --upstream master --rebased rebased [piastry@euclid gitum]$ git show gitum-config:.gitum-config | cat remote = origin/master current = current upstream = master rebased = rebased patches = patches [piastry@euclid gitum]$ gitum remove --full [piastry@euclid gitum]$ gitum create --remote origin/master --upstream master --rebased TEST [piastry@euclid gitum]$ git show gitum-config:.gitum-config | cat remote = origin/master current = current upstream = master rebased = TEST patches = patches [piastry@euclid gitum]$ gitum remove --full У меня всё верно. Могу посмотреть на месте, что там такое.
Добавил к create возможность работать без параметров. В этом случае конфиг файл (и конфиг ветка) не создаются. Далее надо разобраться с веткой rebased - её можно заливать на сервер только через параметр --force, поскольку она всё время обновляется через rebase, что неправильно. Как один из вариантов: генерировать ветку rebased только локально (из ветки patches), а на сервере хранить только upstream, current и patches, которые непрерывны.
Вот так работает нормально: $ gitum create --remote origin/master --upstream master --rebased TEST $ git branch TEST * current gitum-config master patches $ git show gitum-config:.gitum-config | cat remote = origin/master current = current upstream = master rebased = TEST patches = patches А если добавить --patches, то получаем вот что: $ gitum create --remote origin/master --upstream master --rebased TEST --patches patches $ git branch * current gitum-config master patches $ git show gitum-config:.gitum-config | cat remote = origin/master current = current upstream = master rebased = patches patches = patches Воспроизводится на atlant.
Зачем в ветке gitum-config хранится всё дерево исходников в состоянии на момент выполнения gitum create? Может быть, лучше, чтобы там был только файл конфигурации?
(В ответ на comment #49) > Вот так работает нормально: > $ gitum create --remote origin/master --upstream master --rebased TEST > $ git branch > TEST > * current > gitum-config > master > patches > $ git show gitum-config:.gitum-config | cat > remote = origin/master > current = current > upstream = master > rebased = TEST > patches = patches > > А если добавить --patches, то получаем вот что: > $ gitum create --remote origin/master --upstream master --rebased TEST > --patches patches > $ git branch > * current > gitum-config > master > patches > $ git show gitum-config:.gitum-config | cat > remote = origin/master > current = current > upstream = master > rebased = patches > patches = patches > > Воспроизводится на atlant. Спасибо. Поправил ошибку в версии 0.4.2-alt1.
(В ответ на comment #50) > Зачем в ветке gitum-config хранится всё дерево исходников в состоянии на момент > выполнения gitum create? > Может быть, лучше, чтобы там был только файл конфигурации? Это было сделано так, потому что иначе, если создавать пустую ветку, команда create будет работать долго на большом репозитории. Сейчас проверил на репозитории ядра (от коммита 3.0) - время создания пустой ветки и последующий checkout обратно больше 5 минут. К тому же ветку gitum-config не предполагается читать напрямую - она только для gitum команд.
> Это было сделано так, потому что иначе, если создавать пустую ветку, команда > create будет работать долго на большом репозитории. Сейчас проверил на > репозитории ядра (от коммита 3.0) - время создания пустой ветки и последующий > checkout обратно больше 5 минут. К тому же ветку gitum-config не предполагается > читать напрямую - она только для gitum команд. Можно создавать ветку без переключения. Как-то так: blob=`cat <<EOF | git hash-object -w --stdin remote = origin/master current = current upstream = master rebased = rebased patches = patches EOF` tree=`echo 100644 blob ${blob}$'\t'.gitum-config | git mktree` git branch gitum-config `echo "Save config file" | git commit-tree ${tree}`
Работал над задачей: 1) Конфигурационный файл сохраняется в пустой ветке. 2) Изменил логику работы: рабочая ветка rebased, которая существует только локально. 3) Сделал команду update более универсальной (позволяет обновить current и patches любыми изменениями ветки rebased). 4) Добавил возможность восстановления только лишь ветки rebased. 5) Исправил ошибки в pull.
Работал над задачей: 1) Исправлена команды push и clone. 2) Новый порядок аргументов в create. 3) Новое имя по умолчанию для current - mainline. 4) Удалена команда editpatch. 5) Изменено поведение по умолчанию команды restore. 6) Проведено тестирование. 7) Обновлена страничка на wiki. 8) Выпущен новый релиз 0.5.0-alt1 ([#2203] DONE gitum.git=0.5.0-alt1).
Падает при попытке склонировать локальный репозиторий: $ gitum clone ./wine-gitum wine-gitum-2 Traceback (most recent call last): File "/usr/bin/gitum", line 167, in <module> main() File "/usr/bin/gitum", line 144, in main GitUpstream(repo_path=args['repo-dir'], with_log=True, new_repo=True).clone(args['git-repo']) File "/usr/lib/python2.7/site-packages/gitupstream/gitupstream.py", line 280, in clone self._repo.git.fetch('origin') File "/usr/lib/python2.7/site-packages/git/cmd.py", line 219, in <lambda> return lambda *args, **kwargs: self._call_process(name, *args, **kwargs) File "/usr/lib/python2.7/site-packages/git/cmd.py", line 428, in _call_process return self.execute(call, **_kwargs) File "/usr/lib/python2.7/site-packages/git/cmd.py", line 341, in execute raise GitCommandError(command, status, stderr_value) git.exc.GitCommandError: 'git fetch origin' returned exit status 128: fatal: './wine-gitum' does not appear to be a git repository fatal: The remote end hung up unexpectedly
(В ответ на comment #56) > Падает при попытке склонировать локальный репозиторий: > $ gitum clone ./wine-gitum wine-gitum-2 > Traceback (most recent call last): > File "/usr/bin/gitum", line 167, in <module> > main() > File "/usr/bin/gitum", line 144, in main > GitUpstream(repo_path=args['repo-dir'], with_log=True, > new_repo=True).clone(args['git-repo']) > File "/usr/lib/python2.7/site-packages/gitupstream/gitupstream.py", line 280, > in clone > self._repo.git.fetch('origin') > File "/usr/lib/python2.7/site-packages/git/cmd.py", line 219, in <lambda> > return lambda *args, **kwargs: self._call_process(name, *args, **kwargs) > File "/usr/lib/python2.7/site-packages/git/cmd.py", line 428, in > _call_process > return self.execute(call, **_kwargs) > File "/usr/lib/python2.7/site-packages/git/cmd.py", line 341, in execute > raise GitCommandError(command, status, stderr_value) > git.exc.GitCommandError: 'git fetch origin' returned exit status 128: fatal: > './wine-gitum' does not appear to be a git repository > fatal: The remote end hung up unexpectedly На данный момент необходимо указывать полный путь до репозитория: gitum clone /somepath/wine-gitum wine-gitum2 Поддержку короткого пути записал в TODO, спасибо.
Сделать push в пустой репозиторий не получилось: $ mkdir test_repo $ cd test_repo $ git init --bare Initialized empty Git repository in /srv/amorozov/Projects/gitum-test/test_repo/.git/ $ cd ../wine-gitum $ time -p gitum push --remote "$PWD/../test_repo" Traceback (most recent call last): File "/usr/bin/gitum", line 167, in <module> main() File "/usr/bin/gitum", line 162, in main repo.push(args['remote']) File "/usr/lib/python2.7/site-packages/gitupstream/gitupstream.py", line 365, in push self._update_remote(remote) File "/usr/lib/python2.7/site-packages/gitupstream/gitupstream.py", line 393, in _update_remote f.write('%s\n%s' % (remote, self._repo.remote(remote).refs[self._patches].object.hexsha)) File "/usr/lib/python2.7/site-packages/git/remote.py", line 480, in refs assert out_refs, "Remote %s did not have any references" % self.name AssertionError: Remote /srv/amorozov/Projects/gitum-test/wine-gitum/../test_repo did not have any references Command exited with non-zero status 1 real 1586.30 user 1046.83 sys 65.88
(В ответ на comment #58) > Сделать push в пустой репозиторий не получилось: > $ mkdir test_repo > $ cd test_repo > $ git init --bare > Initialized empty Git repository in > /srv/amorozov/Projects/gitum-test/test_repo/.git/ > $ cd ../wine-gitum > $ time -p gitum push --remote "$PWD/../test_repo" > Traceback (most recent call last): > File "/usr/bin/gitum", line 167, in <module> > main() > File "/usr/bin/gitum", line 162, in main > repo.push(args['remote']) > File "/usr/lib/python2.7/site-packages/gitupstream/gitupstream.py", line 365, > in push > self._update_remote(remote) > File "/usr/lib/python2.7/site-packages/gitupstream/gitupstream.py", line 393, > in _update_remote > f.write('%s\n%s' % (remote, > self._repo.remote(remote).refs[self._patches].object.hexsha)) > File "/usr/lib/python2.7/site-packages/git/remote.py", line 480, in refs > assert out_refs, "Remote %s did not have any references" % self.name > AssertionError: Remote > /srv/amorozov/Projects/gitum-test/wine-gitum/../test_repo did not have any > references > Command exited with non-zero status 1 > real 1586.30 > user 1046.83 > sys 65.88 gitum push принимает не путь до репозитория, а удалённый гит репо (git-remote). То есть, нужно сначала git remote add repo1 $PWD/../test_repo а потом gitum push --remote repo1
Склонировать не получилось: $ git remote add test_repo "$PWD/../test_repo" $ gitum push --remote test_repo $ cd .. $ gitum clone "$PWD/test_repo" test_repo_clone Traceback (most recent call last): File "/usr/bin/gitum", line 167, in <module> main() File "/usr/bin/gitum", line 144, in main GitUpstream(repo_path=args['repo-dir'], with_log=True, new_repo=True).clone(args['git-repo']) File "/usr/lib/python2.7/site-packages/gitupstream/gitupstream.py", line 287, in clone self._repo.git.checkout('-b', self._upstream, 'origin/' + self._upstream) File "/usr/lib/python2.7/site-packages/git/cmd.py", line 219, in <lambda> return lambda *args, **kwargs: self._call_process(name, *args, **kwargs) File "/usr/lib/python2.7/site-packages/git/cmd.py", line 428, in _call_process return self.execute(call, **_kwargs) File "/usr/lib/python2.7/site-packages/git/cmd.py", line 341, in execute raise GitCommandError(command, status, stderr_value) git.exc.GitCommandError: 'git checkout -b upstream origin/upstream' returned exit status 128: fatal: git checkout: updating paths is incompatible with switching branches. Did you intend to checkout 'origin/upstream' which can not be resolved as commit?
(В ответ на comment #60) > Склонировать не получилось: > $ git remote add test_repo "$PWD/../test_repo" > $ gitum push --remote test_repo > $ cd .. > $ gitum clone "$PWD/test_repo" test_repo_clone > Traceback (most recent call last): > File "/usr/bin/gitum", line 167, in <module> > main() > File "/usr/bin/gitum", line 144, in main > GitUpstream(repo_path=args['repo-dir'], with_log=True, > new_repo=True).clone(args['git-repo']) > File "/usr/lib/python2.7/site-packages/gitupstream/gitupstream.py", line 287, > in clone > self._repo.git.checkout('-b', self._upstream, 'origin/' + self._upstream) > File "/usr/lib/python2.7/site-packages/git/cmd.py", line 219, in <lambda> > return lambda *args, **kwargs: self._call_process(name, *args, **kwargs) > File "/usr/lib/python2.7/site-packages/git/cmd.py", line 428, in > _call_process > return self.execute(call, **_kwargs) > File "/usr/lib/python2.7/site-packages/git/cmd.py", line 341, in execute > raise GitCommandError(command, status, stderr_value) > git.exc.GitCommandError: 'git checkout -b upstream origin/upstream' returned > exit status 128: fatal: git checkout: updating paths is incompatible with > switching branches. > Did you intend to checkout 'origin/upstream' which can not be resolved as > commit? А какой вывод git branch в репозиторях repo_test (куда делали push) и wine-gitum(откуда делали push)?
В wine-gitum: gitum-config mainline master patches * rebased В test_repo: mainline * master patches
(В ответ на comment #62) > В wine-gitum: > gitum-config > mainline > master > patches > * rebased > > В test_repo: > mainline > * master > patches Спасибо. Исправил в версии 0.5.1-alt1.
(В ответ на comment #63) > (В ответ на comment #62) > > В wine-gitum: > > gitum-config > > mainline > > master > > patches > > * rebased > > > > В test_repo: > > mainline > > * master > > patches > > Спасибо. Исправил в версии 0.5.1-alt1. Нужно заново сделать push на новой версии, чтобы записать ветку gitum-config в test_repo.
> Спасибо. Исправил в версии 0.5.1-alt1. Окей, склонировалось без ошибок. Задумался вот над таким вопросом. С обычным репозиторием схема работы выглядит так. Есть такие репозитории: * копия репозитория апстрима wine-pure, ветка master * репозиторий у нас на сервере eterwine.git, ветка master * репозиторий разработчика: ветка master, репозиторий на сервере - origin/master Разработчик в своём репозитории может добавить wine-pure в качестве remote, сделать merge из wine-pure/master в origin/master и сделать push в репозиторий на нашем сервере В случае gitum: * копия репозитория апстрима wine-pure, ветка master * gitum-репозиторий у нас на сервере * gitum-репозиторий разработчика После клонирования gitum-репозитория у нас на сервере у разработчика в origin/master оказывается не апстрим, а репозиторий на сервере. Поэтому просто gitum merge делать бесполезно. Надо делать gitum merge с указанием --branch. Но тогда непонятно, зачем в конфиге хранить remote = origin/master, если он работает только для локального репозитория.
(В ответ на comment #65) > > Спасибо. Исправил в версии 0.5.1-alt1. > Окей, склонировалось без ошибок. > > Задумался вот над таким вопросом. С обычным репозиторием схема работы выглядит > так. Есть такие репозитории: > * копия репозитория апстрима wine-pure, ветка master > * репозиторий у нас на сервере eterwine.git, ветка master > * репозиторий разработчика: ветка master, репозиторий на сервере - > origin/master > Разработчик в своём репозитории может добавить wine-pure в качестве remote, > сделать merge из wine-pure/master в origin/master и сделать push в репозиторий > на нашем сервере > > В случае gitum: > * копия репозитория апстрима wine-pure, ветка master > * gitum-репозиторий у нас на сервере > * gitum-репозиторий разработчика > После клонирования gitum-репозитория у нас на сервере у разработчика в > origin/master оказывается не апстрим, а репозиторий на сервере. Поэтому просто > gitum merge делать бесполезно. Надо делать gitum merge с указанием --branch. Но > тогда непонятно, зачем в конфиге хранить remote = origin/master, если он > работает только для локального репозитория. Да, тут что-то не то, надо продумать этот момент более тщательно. Небольшое TODO на следующий релиз: 1) Относительный путь к клонируемому репозиторию для gitum clone. 2) Продумать ситуацию с remote апстрим. 3) Продумать ситуацию с несколькими gitum remote репозиториями (что тоже вполне возможный вариант).
> Небольшое TODO на следующий релиз: > 1) Относительный путь к клонируемому репозиторию для gitum clone. > 2) Продумать ситуацию с remote апстрим. > 3) Продумать ситуацию с несколькими gitum remote репозиториями (что тоже вполне > возможный вариант). Занимался данными задачами.
Выпустил версию 0.6.0-alt1.
Я так понимаю, ещё не реализовано: $ gitum merge --branch origin/master --track Traceback (most recent call last): File "/usr/bin/gitum", line 175, in <module> main() File "/usr/bin/gitum", line 111, in main repo.merge(args['branch'], track_with=track) File "/usr/lib/python2.7/site-packages/gitupstream/gitupstream.py", line 69, in merge self._save_urbranch(urbranch) AttributeError: 'GitUpstream' object has no attribute '_save_urbranch'
(В ответ на comment #69) > Я так понимаю, ещё не реализовано: > > $ gitum merge --branch origin/master --track > Traceback (most recent call last): > File "/usr/bin/gitum", line 175, in <module> > main() > File "/usr/bin/gitum", line 111, in main > repo.merge(args['branch'], track_with=track) > File "/usr/lib/python2.7/site-packages/gitupstream/gitupstream.py", line 69, > in merge > self._save_urbranch(urbranch) > AttributeError: 'GitUpstream' object has no attribute '_save_urbranch' Нет, это результат поспешной смены названий функций/переменных. Спасибо. Исправил в версии 0.6.1-alt1.
Выставляю решена.
Склонировать не получается: $ git remote -v etersoft git.eter:/projects/rx/opennx.git (fetch) etersoft git.eter:/projects/rx/opennx.git (push) $ gitum push --remote etersoft --track $ gitum clone git.eter:/projects/rx/opennx.git opennx-gitu Traceback (most recent call last): File "/usr/bin/gitum", line 175, in <module> main() File "/usr/bin/gitum", line 150, in main GitUpstream(repo_path=args['repo-dir'], with_log=True, new_repo=True).clone(args['git-repo']) File "/usr/lib/python2.7/site-packages/gitupstream/gitupstream.py", line 289, in clone self._repo.git.fetch('origin') File "/usr/lib/python2.7/site-packages/git/cmd.py", line 219, in <lambda> return lambda *args, **kwargs: self._call_process(name, *args, **kwargs) File "/usr/lib/python2.7/site-packages/git/cmd.py", line 428, in _call_process return self.execute(call, **_kwargs) File "/usr/lib/python2.7/site-packages/git/cmd.py", line 341, in execute raise GitCommandError(command, status, stderr_value) git.exc.GitCommandError: 'git fetch origin' returned exit status 128: ssh: Could not resolve hostname Etersoft/git.eter: Name or service not known fatal: The remote end hung up unexpectedly в конфиге .git смущает такая строчка: [remote "origin"] url = /srv/baraka/Projects/RX@Etersoft/OpenNX@Etersoft/git.eter:/projects/rx/opennx.git fetch = +refs/heads/*:refs/remotes/origin/*
Исправил проблему с сетевыми именами. Так же исправил работу с бинарными файлами - поэтому gitum update вероятно сработал с ошибкой (он должен был написать в конце) и изменения из rebased не занеслись в patches - при clone получили сломанный репо. Просьба существующее удалить и всё сделать заново, при этом обращая внимание на вывод программы. Версия 0.6.2-alt1.
Запушилось и склонировалось. gitum-0.6.2-alt1
При создании репозитория gitum игнорирует ветку: если я указываю так gitum create --remote origin/ALT/italc2/patchs --upstream upstream --rebased rebased --current mainline --patches patches он всё равно использует origin/master
Поправил в 0.6.3-alt1.
Собрал на git.eter.
Пока закрываю до возникновения новых проблем, а ещё лучше будем создавать новые баги.
gitum update некорректно обрабатывает коммиты с русским комментарием.
Если есть возможность, я бы портировал на python 3. Для нас критерий возможности - это работа в Сизифе (не знаю, каком состоянии модули python 3).
Перенёс два замечания выше в 8984. Эта бага себя исчерпала, закрываю.
