Ignore new commits for git submodule

Solution 1:

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.

Solution 2:

To include another repository, that needn't be tracked in its super-repo, try this:

$ cd /path/to/master/
$ rm -rf book
$ git clone https://[email protected]/user/repo.git book
$ git add book
$ echo "book" >> .gitignore

Then commit.

As stated in the linked git submodule pitfalls article:

... the only linkage between the parent and the submodule is [the] recorded value of the submodule’s checked-out SHA which is stored in the parent’s commits.

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.

Solution 3:

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://[email protected]/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://[email protected]/user/repo.git
    ignore = all

Solution 4:

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.