Подтвердить что ты не робот

Нечего сравнивать. Ничего не сравнится, ветки - это совершенно разные истории фиксации

У меня есть тема CMS, установленная на моей машине. Я отслеживаю изменения в нем через git и решил поддержать его на GitHub, чтобы я мог поделиться этими изменениями.

Тема, представленная, также доступна на GitHub. На моей машине я добавил это как удаленный восходящий поток. Теперь я легко вижу изменения между моим хозяином и удаленный восходящий поток, используя следующую команду:

git diff --color master upstream/number

Если бы я мог добавить удаленный сервер вверх по GitHub, я мог бы легко поделиться этими изменениями. Можно ли установить это отношение на GitHub?

Я пробовал следующее:

git push -u origin upstreambranch

который добавляет upstreambranch к мастеру на GitHub. Однако попытка сравнить обе ветки не работают, результат, который я получаю на GitHub, заключается в следующем: "Там не стоит сравнивать "

Есть ли альтернативный способ их сравнения?

4b9b3361

Ответ 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.