Вопросы Теги

Продвижение существующего репозитория Мерзавца к GitHub только отправляет приблизительно половину фиксаций?

Вы не можете использовать статический файл HTML для файла JSP с принудительным путем. Статический файл HTML предварительно не скомпилирован, и во время выполнения Jetty не может найти предварительно скомпилированный JSP. Он ищет сервлет с именем "jsp", который он может использовать в качестве класса сервлета. Это приведет к ошибке «Нет класса в держателе», так как класс сервлета не найден.

9
задан rpj 26 October 2008 в 21:29
поделиться

7 ответов

Я смотрел на рассматриваемый репозиторий и здесь - то, что продолжалось:

  • В какой-то момент rpj работал git checkout [commit id]. Эта резкая ГОЛОВА в свободной фиксации, а не распознанном ответвлении. Я полагаю, что это - "повисшая ГЛАВНАЯ" проблема, к которой обращается CesarB.
  • Не осознавая эту проблему, он продолжал делать изменение и фиксацию их, которые натолкнулись, ВОЗГЛАВЛЯЮТ каждый раз. Однако ГОЛОВА просто указывала на повисшую цепочку фиксаций, не при распознанном ответвлении.
  • Когда он пошел для продвижения его изменений, мерзавец продвинул все до вершины ведущего устройства, которое было только примерно на полпути через текущее дерево, он шел.
  • Беспорядок последовал

Эта схема должна сделать это более ясным:

                 -- D -- E -- F
                /             ^
   A -- B -- C -              |
   ^         ^               HEAD
   |         |
 remote    master

Когда он пытался продвинуть свои изменения, только A через C были продвинуты и remote перемещенный до C. Он не мог получить фиксации D через F продвигать, потому что на них не ссылается известное ответвление.

Вот то, что Вы видите, когда Вы находитесь в этом состоянии:

$ git branch
* (no branch)
master

Решение состоит в том, чтобы переместиться master до F в повисшей цепочке фиксаций. Вот то, как я сделал это.

  • Создайте законное ответвление для текущего состояния:

    git checkout -b tmp

    • tmp ответвление теперь указывает на фиксацию F в схеме выше

  • Ускоренная перемотка вперед master кому: tmp

    git checkout master

    git merge tmp

    • master теперь указывает на фиксацию F.

  • Выбросьте свое временное ответвление

    git branch -d tmp

  • Можно счастливо продвинуть в удаленный репозиторий, и он должен отправить все изменения.

17
ответ дан 4 December 2019 в 08:17
поделиться

От Мерзавца 1.7.3 вперед, можно сделать это с одной простой командой:

git checkout -B master

-b переключатель означает, “создают ответвление здесь перед проверкой его” и -B безусловная версия этого, “даже если ответвление уже существует – в этом случае, переместите его сюда перед проверкой его”.

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

Так предполагая, что текущая фиксация является той, которую Вы хотите master чтобы быть, Вы просто делаете

git branch -D master

удалить существующее master ответвление, затем сделайте

git checkout -b master

к a) создают новое названное ответвление master это указывает на текущую фиксацию и обновление b) HEAD указать на master ответвление. После этого, HEAD будет присоединен master и поэтому master продвинется каждый раз, когда Вы фиксируете.

5
ответ дан 4 December 2019 в 08:17
поделиться

Проверьте, продвигаете ли Вы корректные ответвления, и что ответвления на самом деле имеют то, что Вы думаете, что они имеют. В частности, проверьте, нет ли у Вас отдельной ГОЛОВЫ, которая может довольно сбивать с толку если не сделанный нарочно.

Самый легкий способ проверить состоит в том, чтобы использовать gitk --all, который показывает графически все ответвления, ГОЛОВУ, и т.д.

2
ответ дан 4 December 2019 в 08:17
поделиться

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

Я никогда не видел эту проблему прежде, и я не могу думать о том, что могло бы быть неправильным.

1
ответ дан 4 December 2019 в 08:17
поделиться

У меня нет репутации для комментария непосредственно более ранний ответ CesarB, но gitk --all не работает в этом случае, потому что это только перечисляет известные ответвления.

gitk HEAD шоу эта проблема, но это не совсем ясно. Дымящееся оружие - это master разоблачает вниз дерево фиксации, а не в новой фиксации.

1
ответ дан 4 December 2019 в 08:17
поделиться

Так, оказывается что оба: хеш фиксации в .git/refs/heads/master был в корректном, и информация в .git/logs/refs/heads/master была неполной; в этом я подразумеваю, что это только подошло и включало хеш фиксации, указанный в .git/refs/heads/master.

После того как я зафиксировал эти файлы (вручную) и пододвинул обратно к GitHub, все было соусом снова. Я все еще понятия не имею, что, оказалось, получило вещи в этом состоянии, но я рад, что, по крайней мере, выяснил фиксацию.

В случае, если любой задается вопросом: для фиксации .git/refs/heads/master я просто заменил содержание того файла с последним хешем фиксации (ГОЛОВА), и зафиксировать .git/logs/refs/heads/master, я просто скопировал содержание .git/logs/HEAD в .git/logs/refs/heads/master. Легкий peasy... НЕТ.

0
ответ дан 4 December 2019 в 08:17
поделиться

Я имел эту ту же проблему дважды и наконец выяснил то, что я делал, который вызывал ее. В процессе редактирования старой фиксации с git rebase -i, вместо вызова git commit --amend, Я звонил git commit -a по привычке, сразу сопровождаемый git rebase --continue, конечно. Кто-то еще смог объяснять, что продолжается негласно, но кажется, что результатом является отдельная ГЛАВНАЯ проблема.

0
ответ дан 4 December 2019 в 08:17
поделиться
Другие вопросы по тегам:

Похожие вопросы: