LINUX.ORG.RU

Как собирать бинарник поочерёдно из разных веток?

 


0

2

Имеется хранилище https://github.com/MeridianOXC/OpenXcom , где в открыто-свободный игровой движок добавляют экспериментальные патчи. В нём — куча веток.

refs/publish/master соответствует «ванильному» оригиналу, где все патчи проверены и одобрены, а требования к качеству кода самые жёсткие.

Всё самое новое и интересное лежит в refs/heads/oxce3.5-plus-proto

Я скачал ветку oxce3.5-plus-proto, собрал и играю. Время от времени обновляюсь гитом и пересобираю (cmake . && make). Когда нахожу баг, обновляю ванильную версию и заодно проверяю на ней.

Вопрос: каким образом переключаться между ветками, чтобы можно было просто отдать команду git, запустить компиляцию и получить искомый бинарник? Помимо хранения 2 экземпляров пакета в разных директориях. Мои попытки это сделать по мануалу пока приводили в лучшем случае к необратимому переключению на master, так что для скачивания «plus» нужно сносить весь архив.

Ответы:

Список внешних репозиториев смотреть командой git remote show. Список веток смотреть командой git remote show ИмяРепозитория. Она выдаст список кратких имён, которые следует использовать вместо длинных.

Параллельный архив советуют создавать командой

git worktree add ../ИмяДиректории oxce3.5-plus-proto
из корня master.

По-видимому, странное поведение вызывалось использованием длинного имени ветки в командах git branch и других, требующих имя ветки.

★★★★★

Последнее исправление: question4 (всего исправлений: 1)

Помимо хранения 2 экземпляров пакета в разных директориях

На самом деле это самый беспроблемный способ (и дело даже не в гите, а в том что переключение веток делает твою старую сборку неактуальной). Используй git worktree

annulen ★★★★★
()
Последнее исправление: annulen (всего исправлений: 2)
Ответ на: комментарий от annulen

Используй git worktree

Спасибо. Только пока не работает. Создаю новую ветку:

git worktree add plus refs/heads/oxce3.5-plus-proto
Запускаю в ней cmake, а он говорит, что последний коммит соответствует ветке master.

Как обновить файлы до последнего коммита в данной ветке?

question4 ★★★★★
() автор топика
Ответ на: комментарий от annulen
$ git checkout refs/heads/oxce3.5-plus-proto
Уже на «refs/heads/oxce3.5-plus-proto»

А собирается из этого ванильная версия. Именно это я имел в виду под «необратимым переключением на master» выше.

question4 ★★★★★
() автор топика
Ответ на: комментарий от question4

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

annulen ★★★★★
()
Ответ на: комментарий от question4

эм, ты создал внутри директории, куда вытащил master, сабдиректорию plus, куда вытащил ветку. начни с того, что дропни эту и создай master и refs/heads/oxce3.5-plus-proto чтобы не разруливать говно внутри .git потом

anonymous
()
Ответ на: комментарий от anonymous

создай master и refs/heads/oxce3.5-plus-proto

создай master и refs/heads/oxce3.5-plus-proto на одном уровне. selffix

anonymous
()
Ответ на: комментарий от annulen

И не стоит таскать везде refs/heads, вполне достаточно oxce3.5-plus-proto

Попробовал. Результат странный:

$ git checkout oxce3.5-plus-proto
Ветка oxce3.5-plus-proto отслеживает внешнюю ветку oxce3.5-plus-proto из origin.
Переключено на новую ветку «oxce3.5-plus-proto»
$ git status
На ветке oxce3.5-plus-proto
Ваша ветка обновлена в соответствии с «origin/oxce3.5-plus-proto».
нечего коммитить, нет изменений в рабочем каталоге
$ git branch
  master
* oxce3.5-plus-proto
  refs/heads/oxce3.5-plus-proto

cmake сообщил, что номер коммита изменился на нужный мне. Компилирую.

Получается, oxce3.5-plus-proto и refs/heads/oxce3.5-plus-proto — разные ветки. Но по ls-remote видна только refs/heads/oxce3.5-plus-proto. При предыдущих попытках создать ветку «oxce3.5-plus-proto» я получал отлуп, что такой нет, поэтому всюду писал длинный путь «refs/heads/oxce3.5-plus-proto». Поэтому следующий вопрос: как просмотреть список веток на сервере? Включая ветки, которые автор тянет от других авторов.

question4 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

ты создал внутри директории, куда вытащил master, сабдиректорию plus, куда вытащил ветку. начни с того, что

создай master и refs/heads/oxce3.5-plus-proto на одном уровне

чтобы не разруливать говно внутри .git потом

Чтобы как описано в первом посте хранить 2 экземпляра пакета? Или нет? Какая принципиальная разница с git worktree? Или ты имеешь в виду 2 параллельных worktree?

question4 ★★★★★
() автор топика
Ответ на: комментарий от question4

oxce3.5-plus-proto и refs/heads/oxce3.5-plus-proto — разные ветки

Нет, второе - это полный вариант записи первого. Но обе ссылаются на твою локальную ветку, которую для начала надо создать из origin/oxce3.5-plus-proto (origin/refs/heads/oxce3.5-plus-proto). Поведение с явным применением refs/heads может быть недружелюбным, так как предполагается что ты продвинутый и тебе надо сделать что-то хитрое

как просмотреть список веток на сервере?

git remote show <название remote>

Включая ветки, которые автор тянет от других авторов.

Это че такое? МОжно увидеть все ветки которые есть на сервере, еслиавтор что-то откуда-то у себя тянет, то увидишь только если он пушит их к себе

annulen ★★★★★
()
Ответ на: комментарий от annulen

Ты создал один worktree внутри другого, а надо было на одном уровне

Это как? Когда я клонирую архив, то он относится к какой-то ветке. master, если явно не указывать иное. Создавать второй worktree находясь на одном с ним уровне не даёт. Надо было из директории, где .git, создавать worktree с путём ../plus ?

question4 ★★★★★
() автор топика
Ответ на: комментарий от annulen

как просмотреть список веток на сервере?

git remote show <название remote>

Спасибо. git remote show показало origin, git remote show origin показало список.

Включая ветки, которые автор тянет от других авторов.

Это че такое? МОжно увидеть все ветки которые есть на сервере, если автор что-то откуда-то у себя тянет, то увидишь только если он пушит их к себе

Понятно. У меня в SVN были проблемы, когда были перемешаны файлы, которые писал один программист, и линки на файлы, которые писал другой программист для другой программы, но первый их тоже использовал. Поэтому спросил.

Насколько я могу судить, в данном случае пушит только master, а остальные ветки получает, руками патча определённые точки master.

Последний вопрос. Откуда терминология «push» и «pull»? Не согласуется с моим интуитивным пониманием «upload» и «download». Можно про это где-нибудь прочитать?

question4 ★★★★★
() автор топика
Ответ на: комментарий от question4

Откуда терминология «push» и «pull»?

Линус так захотел

Кстати pull - это fetch+merge так что это не совсем download

annulen ★★★★★
()
Ответ на: комментарий от question4

Откуда терминология «push» и «pull»? Не согласуется с моим интуитивным пониманием «upload» и «download». Можно про это где-нибудь прочитать?

нет, это не upload и download, это именно «запихнуть» и «вытянуть». если ты хочешь, чтобы в рабочую ветку попали чужие изменения - ты делаешь pull этих изменений. если ты хочешь, чтобы изменения из (локальной) рабочей ветки попали в другую (ремотную) ветку - ты делаешь push этих изменений. отсюда и «pull request», который делается после того, как ты сделал «push» - сначала ты добавляешь изменения в одну ветку через push, а потом просишь, чтобы ответственный за master притащил их в свою ветку, для этого делаешь pull request

//5 звездей, а приходится прописные истины объяснять, дожили

anonymous
()
Ответ на: комментарий от question4

Насколько я могу судить, в данном случае пушит только master, а остальные ветки получает, руками патча определённые точки master.

Эмм... вообще-то push и pull это механизм синхронизации с другим репозиторием, ветки обычно создают локально и потом пушат (если права на это есть)

annulen ★★★★★
()
Ответ на: комментарий от annulen

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

Я имею в виду, что master — копия чужого репозитория, которая обновляется автоматически. В отличии от остальных веток, где все изменения делаются руками.

question4 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

ты делаешь push

чтобы ответственный за master притащил их в свою ветку, для этого делаешь pull request

Всё субъективно, потому что децентрализовано. Понятно.

question4 ★★★★★
() автор топика
Ответ на: комментарий от question4

Я имею в виду, что master — копия чужого репозитория, которая обновляется автоматически.

Копия чужого репозитория - это origin/master, а master - это твоя локальная ветка. Но для нее настроен upstream, поэтому pull ее обновляет

annulen ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.