Я пытаюсь перебазировать ветку поверх master, что я уже делал тысячу раз. Но сегодня он не работает:
> git status
On branch mystuff
Your branch and 'master' have diverged,
and have 6 and 2 different commits each, respectively.
(use "git pull" to merge the remote branch into yours)
nothing to commit, working directory clean
> git rebase
First, rewinding head to replay your work on top of it...
> git status
On branch mystuff
Your branch is up-to-date with 'master'.
Untracked files:
(use "git add <file>..." to include in what will be committed)
[a directory from the project]
nothing added to commit but untracked files present (use "git add" to track)
>
Все начинается как обычно, но затем Git завершает перебазирование, не помещая туда ни одного из моих коммитов; моя ветка mystuff оказывается на том же коммите, что и master.
Очевидным выводом будет то, что мои коммиты уже где-то в мастере. Но это нет, клянусь. Я вернулся к истории. Коммиты есть в паре других веток функций, но их нигде нет в истории master. (И я все равно могу сказать, что они не в мастере по состоянию файлов, когда я извлек мастер.)
Итак, если коммитов еще нет в моей восходящей истории, почему еще git rebase
отказывается размещать мои коммиты сверху?
Как ни странно, если я выбираю коммиты на мастер один за другим, это работает. И тогда я могу переместить свою ветку mystuff в конец и вернуть master туда, где она была. (Но зачем мне это нужно было делать именно так?)
ИЗМЕНИТЬ:
В документации по git rebase
сказано следующее:
Текущая ветвь сбрасывается на
<upstream>
или<newbase>
, если была указана опция--onto
. Это имеет тот же эффект, что иgit reset --hard <upstream>
(или<newbase>
).ORIG_HEAD
указывает на конец ветки перед сбросом.Коммиты, которые ранее были сохранены во временной области, затем повторно применяются к текущей ветке, один за другим, по порядку. Обратите внимание, что любые фиксации в
HEAD
, которые вносят те же текстовые изменения, что и фиксация вHEAD..<upstream>
, опускаются (т. е. уже принятый вышестоящий патч с другим сообщением о коммите или отметкой времени будет пропущен).
Это соответствовало бы поведению, которое я наблюдаю, если бы коммиты действительно существовали вверх по течению... но это не так. И как упоминалось в комментариях, git rebase master
работает корректно и применяет все коммиты. Но git rebase
без master
нет, даже несмотря на то, что master установлен как восходящая ветвь.
Конфигурация моих веток:
[branch "master"]
remote = origin
merge = refs/heads/master
[branch "mystuff"]
remote = .
merge = refs/heads/master
git status
после возвращенияgit rebase
? - person lrineau   schedule 01.04.2014git rebase master
илиgit rebase master <branch>
? - person   schedule 01.04.2014git rebase
иgit rebase --onto master
не работают, как указано выше... ноgit rebase master
работает! Но почему? Если master является восходящим потоком, тоgit rebase
должен работать без аргумента ветки, не так ли? - person Ryan Lundy   schedule 01.04.2014mystuff
? - person joshtkling   schedule 01.04.2014git rebase
будет вести себя иначе, чемgit rebase master
. - person joshtkling   schedule 02.04.2014git rebase
на шаге после извлечения из нашего основного репозитория. Мне никогда не приходилось говорить, какая ветвь. Я использую это с конца 2013 года без проблем до недавнего времени. - person Ryan Lundy   schedule 08.04.2014git
, вызванную использованиемremote = .
. Я бы предложил сделатьgit fsck
, и если ничего не получится, попробуйте сообщить об этом разработчикам git. Если вы не можете поделиться с ними всем репо, я думаю, у них могут быть какие-то скрипты для анонимизации копии репо. - person Mikko Rantalainen   schedule 12.05.2014git rebase -i origin/master
, где-i
означает интерактивный, чтобы увидеть, какие коммиты отображаются в списке. - person Namek   schedule 11.07.2014master
, поняли это, сделалиgit checkout -tb topic && git branch -f master HEAD~... && git rebase
. Кстати, мне интересно, почему вы хотели бы иметьmaster
иtopic
вверх по течению... - person x-yuri   schedule 14.01.2021