git 하위 모듈에 대한 새 커밋 무시

git 하위 모듈에 대한 새 커밋 무시

---

배경

Linux에서 Git 1.8.1.1 사용. 저장소는 다음과 같습니다.

master
  book

하위 모듈은 다음과 같이 생성되었습니다.

$ cd /path/to/master
$ git submodule add https://user@bitbucket.org/user/repo.git book

book서브 모듈은 깨끗합니다 :

$ cd /path/to/master/book/
$ git status
# On branch master
nothing to commit, working directory clean

문제

반면 마스터는 book 서브 모듈에 대한 "새로운 커밋"이 있음을 보여줍니다.

$ cd /path/to/master/
$ git status
# On branch master
# 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:   book (new commits)
#
no changes added to commit (use "git add" and/or "git commit -a")

Git은 서브 모듈 디렉토리를 완전히 무시해야 마스터도 깨끗합니다.

$ cd /path/to/master/
$ git status
# On branch master
nothing to commit, working directory clean

실패한 시도 # 1-더티

master/.gitmodules이 답변에 따라 파일 내부는 다음과 같습니다 .

[submodule "book"]
        path = book
        url = https://user@bitbucket.org/user/repo.git
        ignore = dirty

실패한 시도 # 2-추적되지 않음

master/.gitmodules이 답변 에 따라 다음과 같이 변경 되었습니다 .

[submodule "book"]
        path = book
        url = https://user@bitbucket.org/user/repo.git
        ignore = untracked

실패한 시도 # 3-showUntrackedFiles

master/.git/config이 답변 에 따라 다음과 같이 편집 되었습니다 .

[status]
   showUntrackedFiles = no

실패한 시도 # 4-무시

마스터 무시 파일에 책 디렉토리를 추가했습니다.

$ cd /path/to/master/
$ echo book > .gitignore

실패한 시도 # 5-복제

다음과 같이 마스터에 책 디렉토리를 추가했습니다.

$ cd /path/to/master/
$ rm -rf book
$ git clone https://user@bitbucket.org/user/repo.git book

질문

어떻게 수있는 book서브 모듈은 아래 자신의 저장소 디렉토리에 master저장소 아직 무시 GIT이 book서브 모듈을? 즉, 다음이 표시되지 않아야합니다.

#
#       modified:   book (new commits)
#

git status마스터 저장소에서 실행할 때 해당 메시지를 억제하는 방법은 무엇입니까?

git 하위 모듈 함정 에 대한 기사에서 이것이 부적절한 하위 모듈 사용을 제안합니까?

---

수퍼 저장소에서 추적 할 필요가없는 다른 저장소를 포함하려면 다음을 시도하십시오.

$ cd /path/to/master/
$ rm -rf book
$ git clone https://user@bitbucket.org/user/repo.git book
$ git add book
$ echo "book" >> .gitignore

그런 다음 커밋하십시오.

링크 된 git 하위 모듈 함정 기사에 명시된대로 :

... 부모와 서브 모듈 사이의 유일한 연결은 부모의 커밋에 저장되는 서브 모듈의 체크 아웃 된 SHA의 기록 된 값입니다.

That means that a submodule is not saved by its checked-out branch or tag, but always by a specific commit; that commit (SHA) is saved into the super-repo (the one containing the submodule) like a normal text file (it's marked as such a reference, of course).

When you check out a different commit in the submodule or make a new commit in it, the super-repo will see that its checked out SHA has changed. That's when you get the modified (new commits) line from git status.

To eliminate that, you can either:

• git submodule update, which will reset the submodule to the commit currently saved in the super-repo (for details see the git submodule manpage; or
• git add book && git commit to save the new SHA into the super-repo.

As mentioned in the comments, consider abandoning the book submodule: clone it inside the super-repo, if tracking of its state as part of the super-repo is not necessary.

---

Just run:

$ git submodule update

This will revert the submodule the to old commit (specified in parent-repo), without updating the parent-repo with the latest version of the submodule.

---

There are two kinds of change notices you can suppress (from git 1.7.2).

The first is untracked content which happens when you make changes to your submodule but have not yet committed those. The parent repository notices these and git status reports it accordingly:

modified: book (untracked content)

You can suppress these with :

[submodule "book"]
    path = modules/media
    url = https://user@bitbucket.org/user/repo.git
    ignore = dirty

However, once you commit those changes, the parent repository will once again take notice and report them accordingly:

modified:   book (new commits)

If you want to suppress these too, you need to ignore all changes

[submodule "book"]
    path = book
    url = https://user@bitbucket.org/user/repo.git
    ignore = all

---

Git 2.13 (Q2 2017) will add another way to include a submodule which does not need to be tracked by its parent repo.

In the OP's case:

git config submodule.<name>.active false

See commit 1b614c0, commit 1f8d711, commit bb62e0a, commit 3e7eaed, commit a086f92 (17 Mar 2017), and commit ee92ab9, commit 25b31f1, commit e7849a9, commit 6dc9f01, commit 5c2bd8b (16 Mar 2017) by Brandon Williams (mbrandonw).
^{(Merged by Junio C Hamano -- gitster -- in commit a93dcb0, 30 Mar 2017)}

submodule: decouple url and submodule interest

Currently the submodule.<name>.url config option is used to determine if a given submodule is of interest to the user. This ends up being cumbersome in a world where we want to have different submodules checked out in different worktrees or a more generalized mechanism to select which submodules are of interest.

In a future with worktree support for submodules, there will be multiple working trees, each of which may only need a subset of the submodules checked out.
The URL (which is where the submodule repository can be obtained) should not differ between different working trees.

It may also be convenient for users to more easily specify groups of submodules they are interested in as opposed to running "git submodule init <path>" on each submodule they want checked out in their working tree.

To this end two config options are introduced, submodule.active and submodule.<name>.active.

• The submodule.active config holds a pathspec that specifies which submodules should exist in the working tree.
  • The submodule.<name>.active config is a boolean flag used to indicate if that particular submodule should exist in the working tree.

Its important to note that submodule.active functions differently than the other configuration options since it takes a pathspec.
This allows users to adopt at least two new workflows:

1. Submodules can be grouped with a leading directory, such that a pathspec e.g. 'lib/' would cover all library-ish modules to allow those who are interested in library-ish modules to set "submodule.active = lib/" just once to say any and all modules in 'lib/' are interesting.
2. Once the pathspec-attribute feature is invented, users can label submodules with attributes to group them, so that a broad pathspec with attribute requirements, e.g. ':(attr:lib)', can be used to say any and all modules with the 'lib' attribute are interesting.
   Since the .gitattributes file, just like the .gitmodules file, is tracked by the superproject, when a submodule moves in the superproject tree, the project can adjust which path gets the attribute in .gitattributes, just like it can adjust which path has the submodule in .gitmodules.

---

Nevik Rehnel answer is certainly the correct one for what you are asking: I did not want to have a submodule, how the heck do I get out of that situation?!.

Only, if your master project requires the book submodule, it is a nice gesture to keep it as such because that way other users who checkout your project can then enjoy not having any special git command to run (well... there are some special commands to use submodules, but it still simpler to manage, overall, I think.)

In your case you make changes in the book repository and at some point you commit those changes. This means you have new commits in that submodule, which have a new SHA1 reference.

What you need to do in the master directory is commit those changes in the master repository.

cd /path/to/master
git commit . -m "Update 'book' in master"

This will updated the SHA1 reference in master to the newest version available in the book repository. As a result this commit allows others to checkout all of the master & book repositories at the tip.

So in effect you end up with one more commit whenever you make changes to a submodule. It is semi-transparent if you also make changes to some files in the master repository since you'd commit both at the same time.

---

Run

git submodule update 

at the root level.

참고URL : https://stackoverflow.com/questions/14418352/ignore-new-commits-for-git-submodule