как мне вытащить в голое хранилище - PullRequest
31 голосов
/ 01 сентября 2011

У меня есть «основной» пустой репозиторий и «персональный» пустой репозиторий. Я хочу обновить форму изменений «основной» на «личную», поэтому я запускаю:

$ git pull
fatal: /home/gimenero/applib/git/libexec/git-core/git-pull cannot be used without a working tree.

Как мне вытащить внесенные изменения в "основной"?

Ответы [ 2 ]

45 голосов
/ 01 сентября 2011

A git pull делает fetch с последующим merge, и вы не можете объединиться без рабочего дерева. (Не было бы нигде разрешить конфликты слияния, если бы они возникли.)

Вместо этого вы можете просто получить. Предполагая, что ваш главный репозиторий настроен как удаленный вызываемый источник в вашем личном репозитории:

$ git fetch origin master:master

Обратите внимание, что это будет успешным, только если основная ветвь вашего личного репозитория зеркально отображает основную ветвь основного репозитория. В противном случае Git отклонит выборку без ускоренной перемотки вперед.

24 голосов
/ 03 октября 2014

Обновление с помощью:

$ git fetch origin +refs/heads/*:refs/heads/* --prune

Что это делает?

Сначала отступим: когда мы говорим о ветке с именем "xyz", git фактически обращается к ней как refs/heads/xyz. Но вы можете набрать "xyz" для краткости, потому что иначе это было бы безумием. (Между прочим, теги refs/tags/xyz.) Обычная xyz неоднозначна, поскольку это может быть ветвь, тег или первые N букв хеша коммита. refs/heads/xyz с другой стороны явно представляет ветвь.

Таким образом, даже если вы можете набрать git fetch origin foo:bar, чтобы получить ветку foo с именем bar в своем хранилище, вы можете более явно набрать git fetch origin refs/heads/foo:refs/heads/bar, чтобы сделать то же самое. (Хотя, если foo на самом деле был тегом, а не ветвью, последний потерпит неудачу, потому что их refs/heads/foo не существует. Явность ftw.)

git fetch origin refs/heads/*:refs/heads/* означает все их ветви принадлежат нам . Команда запускается так, как будто часть * заменяется именем их ветви для каждой из их ветвей. то есть git fetch origin refs/heads/abc:refs/heads/abc refs/heads/def:refs/heads/def ... (при условии, что у них есть ветви с именами abc и def).

Опция --prune означает, что любые ветви, которые есть в нашем репозитории, которые соответствуют refs/heads/*, но не существуют в их репозитории, удалены .

Наконец, префикс + разрешает выборки без ускоренной перемотки вперед. Без него любые обновления веток, требующие принудительное обновление , отклоняются.

Если все вместе, конечный результат состоит в том, что ветки в вашем хранилище выглядят точно так же, как и их.

Вот пример вывода:

 - [deleted]               (none)     -> bar
 * [new branch]            foo        -> foo
   4812558a5f..a6aeec6517  abc        -> abc
 + a1b2c3d4e5...1a2b3c4d5e def        -> def  (forced update)
  • Пример говорит нам, что у них есть ветви foo, abc, def, в то время как у нас есть (был) один дополнительный: bar
  • Обратите внимание на удаление bar на --prune и принудительное обновление def, разрешенное префиксом +.

Вот что происходит вместо этого, если + и --prune были отключены:

 * [new branch]            foo        -> foo
   4812558a5f..a6aeec6517  abc        -> abc
 ! [rejected]              def        -> def  (non-fast-forward)

И последнее:

Сравните команду сверху со следующим:

$ git fetch origin +refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/* [--prune]

По сути, это то, что происходит, когда мы набираем git fetch origin [--prune]!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...