Нечего сравнивать. Ничего не сравнится, ветки - это совершенно разные истории фиксации
У меня есть тема CMS, установленная на моей машине. Я отслеживаю изменения в нем через git
и решил поддержать его на GitHub, чтобы я мог поделиться этими изменениями.
Тема, представленная, также доступна на GitHub. На моей машине я добавил
это как удаленный восходящий поток. Теперь я легко вижу изменения между моим хозяином
и удаленный восходящий поток, используя следующую команду:
git diff --color master upstream/number
Если бы я мог добавить удаленный сервер вверх по GitHub, я мог бы легко поделиться этими изменениями.
Можно ли установить это отношение на GitHub?
Я пробовал следующее:
git push -u origin upstreambranch
который добавляет upstreambranch
к мастеру на GitHub. Однако попытка
сравнить обе ветки не работают, результат, который я получаю на GitHub, заключается в следующем: "Там
не стоит сравнивать "
Есть ли альтернативный способ их сравнения?
Ответы
Ответ 1
Короткий ответ
Похоже, что GitHub не позволит вам сравнивать ветки, потому что они не
на самом деле разделяют любую из той же истории вообще,, хотя они могут делиться
большинство файлов и кода.
Вот скриншот временной вилки, сделанной из вашего репо, где я пытался
сравните master
с upstreambranch
, как вы описали. Обратите внимание на ошибку
сообщение:
![Error message screenshot]()
В нем говорится:
Нечего сравнивать.
master
и upstreambranch
- совершенно разные истории фиксации.
Длительный ответ
Вы, вероятно, скачали исходный источник и добавили его в совершенно новый
репо вместо клонирования исходного репо, правильно? Это сделает так
что история вашего репо будет полностью отличаться от
история первоначального репо, так как у вашего нового репо не будет ни одного
фиксируется с одинаковыми идентификаторами шага.
Вы можете видеть, что, делая обратный журнал вашей ветки master
и
upstreambranch
:
# Your first commit, see commit sha
git log --reverse master
commit c548d7b1b16b0350d7fbdb3ff1cfedcb38051397 # <== HERE
Author: Padraic Stack <[email protected]>
Date: Wed Apr 2 15:11:28 2014 +0100
First commit of everything
# First commit sha of the original repo
git log --reverse upstreambranch
commit 105a12817234033c45b4dc7522ff3103f473a862 # <== THERE
Author: Jeremy Boggs <[email protected]>
Date: Mon Feb 22 16:00:53 2010 +0000
Creates repo directories for the Seasons theme.
Решение
Если вы переделаете свои фиксации поверх оригинальной истории, вы должны быть в состоянии
сравнить ветки. Существует несколько способов, с помощью которых можно
совершает, включая
git rebase --onto
и
git cherry-pick
Вы также можете переделать каждую фиксацию вручную, если вам нужно.
Ответ 2
Это выглядит как нежелательное поведение в части github, но его довольно легко исправить. То, что вы хотите сделать, - это переустановить свою ветку на разумную (любую разумную) фиксацию в существующей истории. Что вы можете сделать, так это получить репозиторий github и найти, какое дерево в его истории больше похоже на ту, с которой вы начали. Начните так:
git remote add github u://r/l
git fetch github
myroot=`git rev-list master --max-parents=0`
root_tree=`git rev-parse $myroot^{tree}`
github_base=`git log --pretty=%H\ %T github/master | sed -n "s/$root_tree//p"`
С какой-либо везением, это найдет вам фиксацию в истории github, у которой есть точное дерево, с которого вы начали. Предполагая, что это так,
git rebase --onto $github_base $myroot master
и все готово.
Если это не находит соответствующее дерево, вы можете найти ближайшее приближение. Здесь один из способов получить приблизительную оценку различий:
git log --pretty='echo %H $(git diff-tree -p -b -U0 '$myroot:' %T|wc -l)' github/master \
| sh
который будет подсчитывать строки в минимизированном разбросе между деревом каждой фиксации в истории github/master
и вашим корневым деревом. Кажется разумным надеяться на небольшую небольшую разницу, вы могли бы разглядеть фактический разброс по ней, прежде чем называть, что github_base
совершить и выполнить переадресацию выше.
Ответ 3
Если вы знаете, из чего была начата проблема фиксации, вы можете reset передать свою ветку в эту фиксацию, а затем объединить их.
Ответ 4
Это случилось со мной вчера, потому что я скачал код из исходного репо и попытался вставить его в свое раздвоенное репо, потратить так много времени на поиск решения "Unable to push error" и принудительно его подтолкнуть.
Решение:
Просто восстановите репо, удалив предыдущее, и клонируйте репо из разветвленного репо в новую папку.
Замените файл старым в новой папке и нажмите его, чтобы сделать репозиторий и выполнить новый пулл-запрос.
Ответ 5
Я обнаружил, что ни один из представленных ответов на самом деле не работал у меня; что на самом деле сработало для меня:
git push --set-upstream origin *BRANCHNAME*
После создания новой ветки, она будет правильно отслеживаться. (У меня Git 2.7.4)
Ответ 6
Я не думаю, что здесь есть один и тот же случай, но все же кто-то может найти его полезным.
Когда подобная ошибка произошла со мной, это будет первое слияние и первая фиксация. В онлайновом репозитории ничего не было.
Поэтому не было кода на git -hub, для сравнения с.
Я просто удалил пустой репозиторий и создал новый с тем же именем.
И тогда не было ошибок.
Ответ 7
Я получил это сообщение об ошибке, потому что я переносил приложение из SVN в GitHub, и этого недостаточно, чтобы вызвать git init в местоположении исходного кода, извлеченного из SVN, но вам нужно вызвать git svn clone, чтобы иметь всю историю фиксации.
Таким образом, у двух исходных кодов на GitHub будет общая история, и я смог открыть запросы на pull.
Ответ 8
У меня была проблема, когда я нажимал на свое удаленное репо из локального репо, которое не совпало с историей удаленного. Это то, что сработало для меня.
Я клонировал свое репо локально, поэтому я знал, что работаю со свежей копией репо:
git clone Your_REPO_URL_HERE.git
Перейдите на ветку, которую вы пытаетесь войти в пульт:
git checkout Your_BRANCH_NAME_HERE
Добавить пульт оригинала:
git remote add upstream Your_REMOTE_REPO_URL_HERE.git
Сделайте git fetch и git pull:
git fetch --all
git pull upstream Your_BRANCH_NAME_HERE
Если у вас есть конфликты слияния, разрешите их с помощью
git mergetool kdiff3
или другой инструмент слияния по вашему выбору.
Как только конфликты будут разрешены и сохранены. Зафиксируйте и нажмите изменения.
Теперь перейдите в репозиторий gitub.com оригинала и попытайтесь создать запрос на перенос. У вас должен быть вариант для создания запроса на растяжение и не видеть "Ничего не сравнить, ветки - это совершенно разные истории фиксаций"
Примечание. Возможно, вам понадобится выбрать сравнение между вилами для запроса на тяну.
Ответ 9
Лучший парень, вероятно, прав, что вы скачали вместо клонирования репо при запуске. Вот простое решение, не слишком техническое.
- В новом окне редактора клонируйте свое хранилище в другом каталоге.
- Сделайте новую ветку.
- Затем скопируйте из своего отредактированного окна редактора в новое хранилище с помощью copy paste.
Убедитесь, что все ваши изменения скопированы, посмотрев на вашу старую ветку github.