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://user@bitbucket.org/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.

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.

Run

git submodule update

at the root level.

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 1b614c00 (16 Mar 2017) by commit 1b614c01.
^{(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.