Сообщение Re[3]: git субмодули от 10.07.2024 14:34
Изменено 10.07.2024 14:35 andrey.desman
Re[3]: git субмодули
Здравствуйте, dmitry_npi, Вы писали:
_>У меня похожая ситуация. Каким-то образом сабмодули (но не все, а два из четырех, хз, почему) застряли в состоянии detached, хотя по факту этот коммит и есть последний коммит в мастере. Visual Studio со своим multi-repo support отказывается даже делать Pull. Я просто хочу вернуться в главном репо на мастер, и в сабах тоже на мастер, локальных изменений у меня нет, че делать-то?
Ну смотри, каждый коммит в главном репе ссылается на какой-то конкретный коммит в сабмодуле.
Нет такого, что ссылка идет на ветку мастер сабмодуля, чтобы каждый конкретный коммит главного репа ссылался на определенную версию, а не как повезет.
_>Ок, зашел в саб репо, сделал git checkout master, потом git pull, git status показывает, что изменений в сабмодуле НЕТ (nothing to commit, etc). Но теперь в главном репо я вижу: modified: my-sub-repo (new commits). Студия показывает это:
Да, теперь у тебя сабмодуль в твоей ветке все еще ссылается на старый коммит, а вычекнут другой коммит. Очевидно, ты поменял ссылку.
_>Что это значит, черт побери? Изменений у меня нет, я просто запуллил всё что мог со всех реп. Что он понимает под изменениями и что мне с этим делать? Коммитить? Так зачем, я не собираюсь портить основной мастер ничем. Реверт? Так потом опять выползет.
Если хочешь зафиксировать в своей ветке новую версию сабмодуля, то git add submodule-path / git commit. Иначе ну просто игнорь. Ну а что. Если файл меняешь, тебе же тоже изменения покажет.
_>Пробовал git submodule update --init --recursive, так оно мне потом опять повергает сабрепо в detached.
Конечно, он вычекивает конкретный коммит, на который ссылается твоя ветка. И оно оказывается в detached.
_>Наверно, остается один проверенный путь — нахрен удалить весь каталог и выкачать всё заново. Но лень, потом специфические конфиги по папкам раскладывать.
Ничего не поменяется.
_>
_>----
_>И вопрос, скорее, в КСВ — почему так? зачем мне эти сложности? Я не хотел ничего другого, кроме как выкачать репо с сабрепами, создать ветки для фичи, сделать фичу, закоммитить и вернуться на мастер. Почему для этого необходимо изучать всю подноготную гита, всякие рефы, детачед коммиты? Ну я могу понять, возможно, для разработки ядра линукс такой трэш, где есть сеть независимых репозиториев, где разработка ведется peer-to-peer, а потом еще патчи друг другу шлют — это то что доктор прописал. Но зачем это всё обычным разрабам, кто их всех подсадил на это чудовище?
Ну так сделано. Так работают soft-link'и.
_>У меня похожая ситуация. Каким-то образом сабмодули (но не все, а два из четырех, хз, почему) застряли в состоянии detached, хотя по факту этот коммит и есть последний коммит в мастере. Visual Studio со своим multi-repo support отказывается даже делать Pull. Я просто хочу вернуться в главном репо на мастер, и в сабах тоже на мастер, локальных изменений у меня нет, че делать-то?
Ну смотри, каждый коммит в главном репе ссылается на какой-то конкретный коммит в сабмодуле.
Нет такого, что ссылка идет на ветку мастер сабмодуля, чтобы каждый конкретный коммит главного репа ссылался на определенную версию, а не как повезет.
_>Ок, зашел в саб репо, сделал git checkout master, потом git pull, git status показывает, что изменений в сабмодуле НЕТ (nothing to commit, etc). Но теперь в главном репо я вижу: modified: my-sub-repo (new commits). Студия показывает это:
Да, теперь у тебя сабмодуль в твоей ветке все еще ссылается на старый коммит, а вычекнут другой коммит. Очевидно, ты поменял ссылку.
_>Что это значит, черт побери? Изменений у меня нет, я просто запуллил всё что мог со всех реп. Что он понимает под изменениями и что мне с этим делать? Коммитить? Так зачем, я не собираюсь портить основной мастер ничем. Реверт? Так потом опять выползет.
Если хочешь зафиксировать в своей ветке новую версию сабмодуля, то git add submodule-path / git commit. Иначе ну просто игнорь. Ну а что. Если файл меняешь, тебе же тоже изменения покажет.
_>Пробовал git submodule update --init --recursive, так оно мне потом опять повергает сабрепо в detached.
Конечно, он вычекивает конкретный коммит, на который ссылается твоя ветка. И оно оказывается в detached.
_>Наверно, остается один проверенный путь — нахрен удалить весь каталог и выкачать всё заново. Но лень, потом специфические конфиги по папкам раскладывать.
Ничего не поменяется.
_>
_>----
_>И вопрос, скорее, в КСВ — почему так? зачем мне эти сложности? Я не хотел ничего другого, кроме как выкачать репо с сабрепами, создать ветки для фичи, сделать фичу, закоммитить и вернуться на мастер. Почему для этого необходимо изучать всю подноготную гита, всякие рефы, детачед коммиты? Ну я могу понять, возможно, для разработки ядра линукс такой трэш, где есть сеть независимых репозиториев, где разработка ведется peer-to-peer, а потом еще патчи друг другу шлют — это то что доктор прописал. Но зачем это всё обычным разрабам, кто их всех подсадил на это чудовище?
Ну так сделано. Так работают soft-link'и.
Re[3]: git субмодули
Здравствуйте, dmitry_npi, Вы писали:
_>У меня похожая ситуация. Каким-то образом сабмодули (но не все, а два из четырех, хз, почему) застряли в состоянии detached, хотя по факту этот коммит и есть последний коммит в мастере. Visual Studio со своим multi-repo support отказывается даже делать Pull. Я просто хочу вернуться в главном репо на мастер, и в сабах тоже на мастер, локальных изменений у меня нет, че делать-то?
Ну смотри, каждый коммит в главном репе ссылается на какой-то конкретный коммит в сабмодуле.
Нет такого, что ссылка идет на ветку мастер сабмодуля, чтобы каждый конкретный коммит главного репа ссылался на определенную версию, а не как повезет.
_>Ок, зашел в саб репо, сделал git checkout master, потом git pull, git status показывает, что изменений в сабмодуле НЕТ (nothing to commit, etc). Но теперь в главном репо я вижу: modified: my-sub-repo (new commits). Студия показывает это:
Да, теперь у тебя сабмодуль в твоей ветке все еще ссылается на старый коммит, а вычекнут другой коммит. Очевидно, ты поменял ссылку. (Есть изменения в главном репе, а не в сабмодуле).
_>Что это значит, черт побери? Изменений у меня нет, я просто запуллил всё что мог со всех реп. Что он понимает под изменениями и что мне с этим делать? Коммитить? Так зачем, я не собираюсь портить основной мастер ничем. Реверт? Так потом опять выползет.
Если хочешь зафиксировать в своей ветке новую версию сабмодуля, то git add submodule-path / git commit. Иначе ну просто игнорь. Ну а что. Если файл меняешь, тебе же тоже изменения покажет.
_>Пробовал git submodule update --init --recursive, так оно мне потом опять повергает сабрепо в detached.
Конечно, он вычекивает конкретный коммит, на который ссылается твоя ветка. И оно оказывается в detached.
_>Наверно, остается один проверенный путь — нахрен удалить весь каталог и выкачать всё заново. Но лень, потом специфические конфиги по папкам раскладывать.
Ничего не поменяется.
_>
_>----
_>И вопрос, скорее, в КСВ — почему так? зачем мне эти сложности? Я не хотел ничего другого, кроме как выкачать репо с сабрепами, создать ветки для фичи, сделать фичу, закоммитить и вернуться на мастер. Почему для этого необходимо изучать всю подноготную гита, всякие рефы, детачед коммиты? Ну я могу понять, возможно, для разработки ядра линукс такой трэш, где есть сеть независимых репозиториев, где разработка ведется peer-to-peer, а потом еще патчи друг другу шлют — это то что доктор прописал. Но зачем это всё обычным разрабам, кто их всех подсадил на это чудовище?
Ну так сделано. Так работают soft-link'и.
_>У меня похожая ситуация. Каким-то образом сабмодули (но не все, а два из четырех, хз, почему) застряли в состоянии detached, хотя по факту этот коммит и есть последний коммит в мастере. Visual Studio со своим multi-repo support отказывается даже делать Pull. Я просто хочу вернуться в главном репо на мастер, и в сабах тоже на мастер, локальных изменений у меня нет, че делать-то?
Ну смотри, каждый коммит в главном репе ссылается на какой-то конкретный коммит в сабмодуле.
Нет такого, что ссылка идет на ветку мастер сабмодуля, чтобы каждый конкретный коммит главного репа ссылался на определенную версию, а не как повезет.
_>Ок, зашел в саб репо, сделал git checkout master, потом git pull, git status показывает, что изменений в сабмодуле НЕТ (nothing to commit, etc). Но теперь в главном репо я вижу: modified: my-sub-repo (new commits). Студия показывает это:
Да, теперь у тебя сабмодуль в твоей ветке все еще ссылается на старый коммит, а вычекнут другой коммит. Очевидно, ты поменял ссылку. (Есть изменения в главном репе, а не в сабмодуле).
_>Что это значит, черт побери? Изменений у меня нет, я просто запуллил всё что мог со всех реп. Что он понимает под изменениями и что мне с этим делать? Коммитить? Так зачем, я не собираюсь портить основной мастер ничем. Реверт? Так потом опять выползет.
Если хочешь зафиксировать в своей ветке новую версию сабмодуля, то git add submodule-path / git commit. Иначе ну просто игнорь. Ну а что. Если файл меняешь, тебе же тоже изменения покажет.
_>Пробовал git submodule update --init --recursive, так оно мне потом опять повергает сабрепо в detached.
Конечно, он вычекивает конкретный коммит, на который ссылается твоя ветка. И оно оказывается в detached.
_>Наверно, остается один проверенный путь — нахрен удалить весь каталог и выкачать всё заново. Но лень, потом специфические конфиги по папкам раскладывать.
Ничего не поменяется.
_>
_>----
_>И вопрос, скорее, в КСВ — почему так? зачем мне эти сложности? Я не хотел ничего другого, кроме как выкачать репо с сабрепами, создать ветки для фичи, сделать фичу, закоммитить и вернуться на мастер. Почему для этого необходимо изучать всю подноготную гита, всякие рефы, детачед коммиты? Ну я могу понять, возможно, для разработки ядра линукс такой трэш, где есть сеть независимых репозиториев, где разработка ведется peer-to-peer, а потом еще патчи друг другу шлют — это то что доктор прописал. Но зачем это всё обычным разрабам, кто их всех подсадил на это чудовище?
Ну так сделано. Так работают soft-link'и.