It is a good starting point, but "generally" needs to be emphasized. For utility commands it is always a good idea to read the man utility
page for what is correct syntax.
There is a guideline at The Open Group that can be worth a read. However there is varying level of how conforming implementations are. Some implementations allow one to break this convention, but one should try to heed it as it is both safer and usually more portable (for the day you are on another system with a different implementation.)
When you look at git
and quite a few other tools that is not part of the standard utility package one has to learn the way it is done. The use of command is not unique to git
but also found in others like pactl
/ pacmd
, amixer
etc. As pointed out by @mouviciel this command-based design of git is used by most SCM tools, starting with the old sccs
.
program [options] [command] [arguments]
Here often options
are geared towards the program
itself, and arguments
towards the command
.
It is a nice way to divide an extended a subset for a main program/suite/tool-kit working within a domain.
domain -verbose DO_THIS -with_file filename.txt
domain -verbose DO_THAT -with_file filename.txt
For some it is also given as a short option and by that adhere to the guidelines like e.g. fdisk -l <device>
Enter vs. fdisk <device>
Enter, l
Enter.
When you execute e.g. git config ...
it is not the shell, but git
itself
that interpret that config
is the command. The use of git-config
is more a short way of specifying config
as a git command. Try e.g. man git-config
. By itself it is usually not recognized as a command.
For git
this is also a bit more complex. As it is a tool-kit -> suite, as in many, many commands belonging to git
– it is natural to use a command based implementation. This is a design chosen by the developers of git
itself.
git DO_THIS
Further. As it holds a lot of commands, they have divided the commands in several groups where the two main is classified as Plumbing and Porcelain. Also see: What does the term porcelain mean in Git?. The manual page has a ordered grouping starting from GIT COMMANDS
.
Further one can also customize, trough configuration files, what some of the commands do. As an example. You can view differences between commits by git diff
. This command can be customized in your .gitconfig
. You can specify which diff program to use and how it should be called.
To make help for various commands easily accessible one also has the possibility to say:
git help command
so git help commit
, gives you help for git
's commit
command.
Guess it could help if you see git
as a command line suite, or even a menu driven command environment. As with a GUI application where you can click File->Open->[Some file]
, a command driven suite could have suite open <file>
.
You could use a filter:
git config filter.dropSecondLine.clean "sed '2d'"
Edit/create .git/info/attributes and add:
* filter=dropSecondLine
If you don't want the filter acting on all the files in the repo, modify the * to match an appropriate pattern or filename.
The effect will be the working directory will remain the same, but the repo blobs will not have the second line in the files. So if you pull it down elsewhere the second line would not appear (the result of the sed 'd2'). And if you change the second line of your log file you will be able to add it, but not commit it, as the change to the blob happens on add, at which point it will be the same file as the one in the repo.
Best Answer
For diff, there's
git diff --ignore-space-at-eol
, which should be good enough. For diff and blame, you can ignore all whitespace changes with-w
:git diff -w
,git blame -w
.For
git apply
andgit rebase
, the documentation mentions--ignore-whitespace
.For merge, it looks like you need to use an external merge tool. You can use this wrapper script (untested), where
favorite-mergetool
is your favorite merge tool; rungit -c mergetool.nocr.cmd=/path/to/wrapper/script merge
. The result of the merge will be in unix format; if you prefer another format, convert everything to that different format, or convert$MERGED
after the merge.To minimize trouble with mixed line endings, make sure text files are declared as such.
See also Is it possible for git-merge to ignore line-ending differences? on Stack Overflow.