git добавить ветку удаленного отслеживания в голое РЕПО

  1. у меня есть голый РЕПО, который был клонирован из git.drupal.org.
  2. я клонировал с этого голого РЕПО на различные веб-сайты.
  3. из каждого из них я толкаю ветку для конкретного сайта на голое РЕПО.

Например, если у меня есть foo.org и еще bar.org, тогда у моего голого РЕПО есть ветви drupal + одна под названием foo и одна под названием bar.

Идея заключалась в том, что я мог бы максимально использовать жесткие ссылки git, чтобы сэкономить место на диске с локальными клонами. Я думал, что оставлю его себе. голое РЕПО извлечение из git.drupal.org, и потяните изменения вниз к моим локальным копиям, foo & bar. Тогда, когда появится обновление, это будет легко. 
bare-repo$ git fetch >/dev/null ; git branch -a
* 7.x
  foo
  bar
  remotes/origin/7.x
  remotes/origin/8.x
Фу и бар отправились на ветку 7.x но я хотел бы обновить их до 7.8, например, с помощью git rebase 7.8 , но это не удается: 
fatal: Needed a single revision
invalid upstream 7.8

Фу и бар не могут "видеть" пульты голого РЕПО. Что я могу сделать?

2 3
remote-branch git-branch git-bare

2 ответа:

2 пункта, как описано в "git rebase fatal: требуется одна ревизия":

  • вам нужно указать имя ветви, которое в вашем случае будет origin/7.8, а не 7.8: 
   git rebase origin/7.8

Должно сработать.

  • вы не можете перебазироваться в ветвь, которая не содержит фиксации, на которой изначально была создана ваша текущая ветвь. (поэтому убедитесь, что это относится к вашему РЕПО)

The OP artfulrobot отчеты: 

git rebase origin/7.8 
fatal: Needed a single revision invalid upstream origin/7.8

На что я ответил:

Если 7.8 не присутствует в origin как ветвь, ожидается это сообщение об ошибке.
Может быть 7.8 является тегом в репо 'origin'.
В этом случае сначала нужно явно извлечь указанные теги : 

git fetch --tags origin

Тогда ребаза должна работать

2

Вам нужна рабочая папка для перебазирования. Поэтому вам нужно клонировать это РЕПО, а затем делать то, что вам нужно. После этого отодвиньте модифицированные ветви обратно в голое РЕПО.

В качестве альтернативы можно указать рабочий каталог git --work-tree=../somedir rebase 7.8. К сожалению, параметры worktree и Git dir для команды git не полностью реализованы для всех команд. Первый вариант-самый лучший.

Rebase нуждается в работающем dir, потому что он должен дать вам контроль, когда он сталкивается с конфликтом. Затем вы можете исправить конфликт и выдать команду git rebase --continue, чтобы позволить ему применить остальные коммиты на новой базе.

Надеюсь, это поможет.

2