An anomaly, not a bug

Concerning ".gitignore", experienced using git 2.10.0

Starting code using one or more spaces or tabs from the left margin will have git reading .gitignore and ignoring(or un-ignoring) the command-instruction.

Example: Starting .gitignore

/*
        # above line is duly read.  Then un-ignoring
        # something but starting the command further to the
        # right will have git not reading that line

  !/nottobeignored.file

End .gitignore

Note: the comments can be started away from the left margin,
as normal in all unix-linux configuration files we know of.
Git follows this behaviour fine.

The lines containing commands, on the contrary of regular convention cannot be indented by spaces or tabs. Quite unusual, confusing, not in the sense of conventional and easily adverted in coding git.

Could be we are missing out on something,

Git command line tool is a functional tool now in our setup for two years, first noticed this alien behaviour in this version of git, on osx, the fink(osx package mananger) binary.

Actually, git reads

    # comment

as 'ignore files with name " " (4 spaces)', and then a comment. It does not ignore the leading whitespace.

Even not as a comment, it treats it as literally a filename with a hash and that comment in it. However, one (usually) does not name their files like that, so for all purposes this can be thought of as a sort of comment.