Что может привести к изменению «количества коммитов вперед» после перебазирования? - PullRequest
Новая
       2

Что может привести к изменению «количества коммитов вперед» после перебазирования?

3 голосов
/ 15 февраля 2011

До того, как я отказался от ветки функций, которой я не занимался в течение нескольких недель, он был на 25 коммитов впереди мастера.После перебазирования теперь 18 коммитов.По пути мне пришлось разрешить несколько конфликтов.Возможно, ровно 7.

Что может вызвать изменение этого номера?Вишневые кирки, которые были обнаружены по пути и превращены в коммиты NOOP?Вышеупомянутые разрешения конфликтов?

Ответы [ 2 ]

4 голосов
/ 16 февраля 2011

Есть несколько возможных способов, которыми это может произойти - это не исчерпывающий список, но он должен дать вам представление о том, как это может произойти:

1. Вишневые коммиты

Во-первых, вы упомянули возможность того, что коммиты из вашей ветки были выбраны вишней в ветвь вверх по течению, на которую вы перебазировали: просто чтобы подтвердить это, git rebase пропустит любые такие коммиты, которые могут составлять некоторую часть несоответствия. Более подробно об этом можно узнать из ответа VonC на вопрос .

2. Конфликты разрешены именно к исходной версии

Мое первоначальное подозрение состояло в том, что, когда вы перебазировали и видели конфликты, вы всегда разрешали их, выбирая исходную версию, а не свои изменения. (Если это не звучит как колокольчик, то мое подозрение, вероятно, совершенно неверно :)) Если не было никаких других неконфликтующих изменений, внесенных этим коммитом, то, что будет сделано для разрешения конфликта, это просто сделает дерево таким же как это было до того, как он попытался применить патч из ваших изменений, так что нечего коммитить.

К сожалению, подсказки, которые выдает git, когда это происходит, могут быть довольно запутанными. Вот пример того, что вы увидите с помощью git 1.7.1. Сначала внесите изменение, которое вступит в конфликт с изменением, которое еще не было объединено с origin / master: 

$ git commit
[master 1efa20f] Add a change designed to conflict
 1 files changed, 1 insertions(+), 1 deletions(-)

... теперь начните ребаз: 

$ git rebase origin/master 
First, rewinding head to replay your work on top of it...
Applying: Add a change designed to conflict
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging src-plugins/3D_Viewer/ij3d/Image3DUniverse.java
CONFLICT (content): Merge conflict in src-plugins/3D_Viewer/ij3d/Image3DUniverse.java
Failed to merge in the changes.
Patch failed at 0001 Add a change designed to conflict

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

Посмотрите на то, что конфликт был: 

$  git diff
diff --cc src-plugins/3D_Viewer/ij3d/Image3DUniverse.java
index 36ec046,f4841ec..0000000
--- a/src-plugins/3D_Viewer/ij3d/Image3DUniverse.java
+++ b/src-plugins/3D_Viewer/ij3d/Image3DUniverse.java
@@@ -264,7 -264,7 +264,11 @@@ public class Image3DUniverse extends De
        public void cleanup() {
                timeline.pause();
                removeAllContents();
++<<<<<<< HEAD
 +              contents.clear();
++=======
+               contents.clear(); // A change designed to conflict
++>>>>>>> Add a change designed to conflict
                universes.remove(this);
                adder.shutdownNow();
                executer.flush();

Я решил, что мне нравится версия из апстрима, поэтому отредактируйте файл, чтобы решить это: 

$  vim src-plugins/3D_Viewer/ij3d/Image3DUniverse.java

Стадия разрешения этого конфликта: 

$ git add src-plugins/3D_Viewer/ij3d/Image3DUniverse.java

Теперь попробуйте продолжить как обычно: 

$ git rebase --continue
Applying: Add a change designed to conflict
No changes - did you forget to use 'git add'?

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

Я думаю, что в более поздних версиях git, это говорит о том, что вы, возможно, только что разрешили коммит на то, что уже было там, и что вам следует подумать о выполнении git rebase --skip. Однако обычно люди понимают, что это единственный выход из этой ситуации, так что: 

$  git rebase --skip
HEAD is now at f3a2de3 3D Viewer: Avoid NPE when closing the viewer window.
Nothing to do.

Этот коммит теперь не будет отображаться в git log.

3. Слияние совершает

Вы упоминаете в комментариях ниже, что видели несколько коммитов слияния при последующем рассмотрении двух ветвей - это также может быть причиной пропущенных коммитов, поскольку git rebase по умолчанию игнорирует любые коммиты слияния, когда он готовит свой список коммитов к повторно наверх по течению.

1 голос
/ 16 февраля 2011

Чтобы немного расширить комментарий Джефроми, вы можете сравнить выходные данные git log --pretty=oneline -n18 <branch> с git log --pretty=oneline -n25 <branch>@{1} и посмотреть, какие коммиты пропали без вести.Как он упомянул, вам может понадобиться немного использовать git reflog, если вы проделали некоторую работу с тех пор, чтобы определить, какая запись является вашей ветвью ветки перед ребазой.

...