2013-08-15 2 views
4

Я клонировал мой новый репозиторий из Github и файл FETCH_HEAD в рабочем каталоге -> .git содержит следующее:EGit не-для слияния

fe300b2c9852acf68b4f1dd78ace916a083f3236 not-for-merge branch 'master' of ssh://[email protected]/mike123/myRepo.git 

Что не-для-слияния значит?

ответ

0

В принципе, git fetch извлекает ветви и сохраняет результат в файле FETCH_HEAD. Когда он запускается как часть git pull, эта информация позже используется внутри, чтобы решить, что нужно объединить.

В случае выборки нескольких ветвей позже сливаются только те, которые не помечены как not-for-merge. См. Также this blog post by Junio.

В вашем случае JGit (библиотека, используемая EGit для работы с репозиториями Git), по-видимому, ведет себя иначе, чем реализация Git в командной строке. В командной строке Git нет FETCH_HEAD сразу после клонирования. Но после первого раза вы тянете, файл есть. Попробуйте потянуть и посмотреть, как изменяется файл. Однако эта разница в реализации не принесет никакого вреда.

+0

Я не совсем следую за тобой. Я пробовал несколько тестов, и я не могу найти случай, когда FETCH_HEAD не содержит not-for-merge. Не могли бы вы показать шаги для достижения этого? – mike

+0

@mike: повторите клонирование хранилища, создайте новую ветку и нажмите ее, затем извлеките из исходного клона и проверите 'FETCH_HEAD'. – robinst

+0

Я все еще не вижу никакой разницы в FETCH_HEAD. Я пробовал это с новым репо. (только одна ведущая ветвь с README, содержащая по умолчанию две строки в ней, созданные Github). Затем я клонировал дважды. Во втором экземпляре я создал новую ветку.Я основал этот новый филиал на удаленной ветке отслеживания. Затем я попытался подтолкнуть новую ветку как с первой, так и без нее. Но когда я возвращаюсь к первому клону и получаю, у меня все еще нет-для-слияния в FETCH_HEAD. – mike

0

EGit основан на JGit, и «not-for-merge» используется только в org.eclipse.jgit.transport.FetchHeadRecord

Это notForMerge переменная FetchHeadRecord устанавливается в методе org.eclipse.jgit.transport.FetchProcess#want.

fhr.notForMerge = spec.getDestination() != null; 

Если refspec назначение не равно нуля, то это неправдоподобная голова не для слияния.

При выборке пульта дистанционного управления, назначение удаленного ветвей refs/remotes/yourRemote, из-за локальной конфигурации для выборки refspec:

[remote "origin"] 
    fetch +refs/heads/*:refs/remotes/origin/* 

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

[branch "master"] 
     remote = origin 
     merge = refs/heads/master 

Именно поэтому, после извлечения из JGit репо (в командной строке, а не в Eclipse, EGit), я вижу:

C:\Users\VonC\prog\git\jgit\.git>type FETCH_HEAD 
c2a9f9e742f7e6633af130823c154a485e6071b2    branch 'master' of https://github.com/eclipse/jgit 
51d1af9489924ff03fa10ec963110c608c2882a3  not-for-merge branch 'stable-0.10' of https://github.com/eclipse/jgit 
989149736ad1cd09c15e143aa598028b9f9b6502  not-for-merge branch 'stable-0.11' of https://github.com/eclipse/jgit 
b2b58feba7400269df8b31ef8495b695af3a9793  not-for-merge branch 'stable-0.12' of https://github.com/eclipse/jgit 

Давайте попробуем воспроизвести, что в EGit/JGit (Luna, EGit 3.0, Win7 64-бит):

После нескольких выборки, я никогда не видел запись безnot-for-merge хотя.
Даже тянуть, который объединит новые comits из удаленного филиала будет по-прежнему генерировать FETCH_HEAD с:

220c4502ecea147ef4beaae8039b168965e148e9 not-for-merge branch 'master' of ..\..\jgit 

Я предполагаю, что поведение JGit отличается от этого аспекта.

+0

OK, вы подтвердили, что я сказал robinst, что не для слияния всегда находится в 'FETCH_HEAD' Но вопрос остается, если не-для-merge всегда находится в 'FETCH_HEAD', даже когда вытягиваете, то как« FETCH_HEAD »вписывается в процесс? – mike