Игнорировать изменения в подмодуле git

Question

Я знаю, что уже есть один вопрос по этому вопросу в Stackoverflow . Но это говорит о том, как избежать такой ситуации, когда мы хотим с самого начала игнорировать новые коммиты. У меня уже есть репозиторий Go, в котором есть каталог go-build, который сам по себе является подмодулем. Когда я делаю git status, я получаю следующее сообщение:

On branch x/y
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   go-build (new commits)

no changes added to commit (use "git add" and/or "git commit -a")

Можно ли сохранить изменения локально, но не нажимать коммиты в go-build на master? Я видел, что есть способ сделать это для каталогов / файлов, добавив их в файл .git / info / exclude, но это не сработало для подмодуля.

Answer 1

Можно ли сохранить изменения локально, но не нажимать коммиты в go-build на master?

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

Ключевым моментом здесь является понимание того, что каждый подмодуль является своим собственным отдельным частным хранилищем. Суперпроект - репозиторий Git, который ссылается на подмодуль - содержит три фрагмента информации. Два из них вы должны передать git clone для получения хранилища субмодулей:

git clone <url> <path>

Третий фрагмент информации сохраняется в каждом коммите ¹ в суперпроекте, и это необработанный хэш-идентификатор одного конкретного коммита, который вышеуказанный git clone должен проверить после завершения клона.

Если в вашем подмодуле есть новые коммиты, которые вы не не доставили в другое место, но в своем суперпроекте вы делаете записывает хэш-идентификатор одного из этих новых коммитов, который не существует тогда где-нибудь еще:

• любой иначе , который запускает git clone, получит клон подмодуля, но
• когда их суперпроект Git переходит к git checkout указанному хеш-идентификатору, этот хеш-код не будет существовать в их клоне субмодуля

чтобы они получили ошибку.

С другой стороны, если вы не записываете новый хэш-идентификатор в суперпроекте, то тот, кто делает клон вашего суперпроекта, и просит своего клона также клонировать подмодуль, проверьте старый хеш-идентификатор, который будет в порядке, но у них будет другой субмодуль , проверенный вами, чем вы. Их сборка может или не может работать, в зависимости от того, что изменилось в подмодуле.

С третьей стороны, ² вы всегда можете просто продолжить и зафиксировать новый хэш-идентификатор в суперпроекте, потому что ваш суперпроект предположительно уже имеет более ранние коммиты, которые работают с более ранней версией субмодуля. Поэтому любой, у кого есть проблема, описанная на этапе «из первых рук», может просто проверить более раннюю фиксацию в суперпроекте. В связи с этим не требуется, чтобы вы отправляли этот конкретный коммит суперпроекта в любом месте - в этом случае другие пользователи суперпроекта никогда даже не увидят этот коммит с новым хеш-идентификатором для подмодуль. В этом случае проблемы просто не возникает.

Следовательно, все зависит от того, что вы хотите получить в результате .

---

¹ Технически это объект tree , либо объект дерева верхнего уровня коммита, либо некоторое поддерево, в зависимости от <path> для подмодуля. Ключевое различие между этой и двумя другими частями информации заключается в том, что две другие находятся в обычном файле, который каждый может прочитать или отредактировать: файл с именем .gitmodules. Хэш-идентификатор фиксации хранится во внутреннем объекте Git, который пользователи обычно не видят напрямую.

² Либо сжимающая рука , либо, возможно, первая нога.