I have some that has been changed but I don’t want to commit, just keep it in the working directory as it is.
…
Is there a way to tell Git these modifications are not to be committed, but let me know if there is any other change?

You need to embrace temporary commits!

You absolutely should check in those temporary changes on your branch while working on it as separate, temporary commits (and with commit messages that clearly stands out that they are temporary). Later however, when completing the work on the branch, then those temporary commits can be removed.

Let’s say the changes you are concerned with are various debug print statements (with printf, _logger.info, console.log or whatever logging mechanism that is appropriate), spread around all over the place in multiple files.

• Axiom 1: Adding such temporary print statements while working on some feature is perfectly fine and normal.
• Axiom 2: Not wanting to pollute the history of your project with those temporary print statements is good.

But not creating commits for those temporary changes is wrong because

• Axiom 3: The only sensible way to handle such temporary changes is to check them in to git as temporary commits!

As an example assume you have been working on adding some foo
functionality, have modified bar a bit and are now ready to complete
the work. You have created a couple of temporary commits (that all start and end with the characters “====”¹), so to remove those temporary commits you start an interactive rebase and are presented with the following list:

pick 10001 Started implementing foo
pick 10002 ==== debug foo ====
pick 10003 Finished implementing foo
pick 10004 Improved bar
pick 10005 ==== debug bar ====
pick 10006 ==== more foo debug ====
pick 10007 Removed unused baz
pick 10008 ==== more bar and foo debug ====

This is trivial to trim down to the following:

pick 10001 Started implementing foo
pick 10003 Finished implementing foo
pick 10004 Improved bar
pick 10007 Removed unused baz

which satisfies axiom 2.

If you’re not constantly rewriting the (local) history in git, you’re doing git wrong.

If you consider commits and branches as immutable objects you are missing out on the vast majority of git’s benefits.

The benefits of checking in temporary changes as temporary commits are many:

• There are no outstanding changes that prevents you from switching to a different branch.
• They can be cherry-picked.
• They can be rebased.
• They can quickly be temporary disabled with git revert.
• They can quickly dropped with interactive rebase (e.g. you no longer need to have the foo debug messages, but want to keep bar debugging).
• They could eventually be shared with other people (they just need to be aware with your naming convention).
• There is no git repo specific configuration.
• You have the debug print statements available when running git bisect later for instance.
• They have the same visibility as other commits in git log and gitk.

Thus you do not need “another kind of index”, in fact the temporary commits are and should be treated as normal commits. The only “special” handling is to make the commit messages be enough different that they stand out as temporary commits, and to filter them out with interactive rebase at the end.

But what about conflicts during interactive rebase?

Use my script git-resolve-conflict-using-kdiff3. KDiff3 automatically resolves lines removed next to lines above/below that are changes (and if manual conflict resolution should be required KDiff3 is an awesome tool to use for that as well).

---

¹ You can use whatever indicator you want, “====” is just a
suggestion. It just needs to clearly stand out in the list of commits
when doing an interactive rebase.