An anomaly, not a bug

An anomaly, not a bug

[m.]

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.

Re: An anomaly, not a bug

[Alexei Lozovsky]

> 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.

Actually, git reads

    # comment

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

Re: An anomaly, not a bug

[Alexei Lozovsky]

> 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.