The commands:
git config --list --show-origin
and
git config --show-origin --list
are the same command with the switch/flag order swapped around. Both commands work on Git Bash for Windows, so obviously for some commands, when using the command with multiple switch/flags, the switch/flag order doesn't matter...
BUT
are there commands where the switch/flag order does matter?
Yes, there are. git rev-parse prints output in the order that the arguments appear. So if you run git rev-parse --absolute-git-dir --git-common-dir, that will produce different output than git rev-parse --git-common-dir --absolute-git-dir.
Additionally, while some programs, including some, but not all, Git subcommands, accept options and arguments in any order, that's not guaranteed to work, and when scripting especially, you should always assume that all options must precede all non-option arguments, since this behaviour is required by POSIX.
Related
This question already has answers here:
Git branch command behaves like 'less'
(9 answers)
Closed 11 months ago.
I'm a little confused with the following behavior of git commands in the Windows Command prompt.
This shows a result comparable to VIM (I think) with interactive list
git branch -a
Result is something like the following and I've no idea what key-combinations to use to scroll through the output (I did notice that q ends the output).
But this shows a "normal" result by just dumping the output to stdout
git show-ref --tags --heads
which is what I prefer:
How to make all output be just dumped to stdout?
I'd prefer if all commands work the same way. Esp if I want to automate a git command in a batch script or something, I cannot use some kind of interactive shell.
I noticed that this behavior seems to be caused by the TERM=msys environment variable setting, which, if absent, behaves the same. I don't know if there's a different setting I can use.
In the end, while the colored result may be fun, I can get that by using Git BASH. But when I run the commands directly from the Windows Command, I'd expect them all to just echo the output to stdout.
I can't remember that this was the behavior previously, so my guess is that I installed something that f'ed things up ;). I'm on Windows 10 for this machine, git, bash etc are latest.
This is what git calls a pager. You can disable it for a particular command with:
git --no-pager branch -a
(Note that --no-pager goes between git and the subcommand, because it is a global switch).
If you want to configure your system so you don't have to remember that, from man git-config:
pager.<cmd>
If the value is boolean, turns on or off pagination of the output of a particular Git subcommand when writing to a tty. Otherwise, turns on pagination for the subcommand using the pager specified by the value of pager.<cmd>. If --paginate or --no-pager is specified on the command line, it takes precedence over this option. To disable pagination for all commands, set core.pager or GIT_PAGER to cat.
That is, you can disable the pager for git-branch only with git config --global pager.branch false, for example.
And if you want to disable it for all commands do git config --global core.pager cat. Or you can try to set the environment variable GIT_PAGER=cat, of course.
Currently, when inside git repos, I type git status. Is there any way for my shell to understand this is a git repo and automatically append git to relevant commands?
e.g.,
# bash example
# before
git status
# after
status # "status" isn't a registered command, but "git status" is, so bash uses the latter
I'd probably only want this enabled when I'm in a repo, but is there any way to get functionality similar to this in any of the popular shells?
I recognize this isn't always preferred or the best idea, but it could save me from typing a word.
This is what aliases were invented for in bash. You'd add a line to your bashrc that looked like this:
alias status='git status'
If you'd like, you could add one for every git subcommand you ran frequently:
alias commit='git commit'
alias checkout='git checkout'
alias add='git add'
alias push='git push'
alias pull='git pull'
alias config='git config'
Your environment is your own, and if you wanna make a shorthand for git commands, you're free to do so!
Also, these aliases will pass any arguments to the underlying command. So if you write:
commit -m "My message"
This will translate to git commit -m "My message".
These aliases should be added to a file like the .bashrc file in your home directory, if one exists.
See here for a more in-depth explanation of aliases.
git branch drops the output to, seemingly, vim rather than just dumping the branch list straight to the terminal.
I know I could do something like git config alias.ls '!git branch | cat' but that doesn't play well with arguments.
Is there a way to simply disable git from redirecting to vim?
Fwiw, I'm using Oh My ZSH / ZSH; however, I tried similar commands in vanilla bash in both iTerm2 and Terminal with the same results.
Usually the pager you're using is less, unless otherwise specified. However, regardless of the pager you're using, you can turn it off.
If you want the pager off for one command, do git --no-pager branch (for example), but note that the --no-pager goes before the command. This is great for aliases. If you want the pager off for all commands, set core.pager to cat, and Git will not invoke the pager. There is not a way to disable it just for one command and not others.
Note that the pager is not invoked by default for commands where the output is not a TTY, so if you're scripting, it's automatically disabled.
The git help command on Windows (msysgit distribution) spawns web browser each time I run it. I tried git help -m which reports "No manual entry for ..." and git help -i which says "info: Terminal type 'msys' is not smart enough to run Info." The same happens in bash under Cygwin.
Is there any sensible way to get light-weight help in cmd terminal?
It works for particular commands: git <command> -h
Edit, thanks to #the-happy-hippo
But it shows only a brief description, not the full one, as git help <command> or git <command> --help gives on Windows.
git <verb> -h shows a command usage in the same terminal window.
On the other hand, git <verb> --help and git help <verb> open a browser.
Update for Git 2.x (June 2017, Git 2.13.1)
You still don't have man:
> git -c help.format=man help add
warning: failed to exec 'man': No such file or directory
fatal: no man viewer handled the request
Same for git <verb> --help.
git <verb> -h does not print the man page, only the short usage section (nothing to do with man)
With Git 2.34 (Q4 2021), when git cmd -h shows more than one line of usage text (e.g. the cmd subcommand may take sub-sub-command), parse-options API learned to align these lines, even across i18n/l10n.
See commit 4631cfc (21 Sep 2021), and commit 84122ec, commit 78a5091, commit 5d70198 (13 Sep 2021) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit d7bc852, 13 Oct 2021)
parse-options: properly align continued usage output
Signed-off-by: Ævar Arnfjörð Bjarmason
Some commands such as "git stash"(man) emit continued options output with e.g. git stash -h, because usage_with_options_internal() prefixes with its own whitespace the resulting output wasn't properly aligned.
Let's account for the added whitespace, which properly aligns the output.
The "git stash" command has usage output with a N_() translation that legitimately stretches across multiple lines;
N_("git stash [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]\n"
" [-u|--include-untracked] [-a|--all] [-m|--message <message>]\n"
[...]
We'd like to have that output aligned with the length of the initial "git stash" output, but since usage_with_options_internal() adds its own whitespace prefixing we fell short, before this change we'd emit:
$ git stash -h
usage: git stash list [<options>]
or: git stash show [<options>] [<stash>]
[...]
or: git stash [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] [-m|--message <message>]
[...]
Now we'll properly emit aligned output.
I.e.
the last four lines above will instead be (a whitespace-only change to the above):
[...]
or: git stash [push [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] [-m|--message <message>]
[...]
This change is relatively more complex since I've accounted for making it future-proof for RTL translation support.
Later in usage_with_options_internal() we have some existing padding code dating back to d7a38c5 ("parse-options: be able to generate usages automatically", 2007-10-15, Git v1.5.4-rc0 -- merge) which isn't RTL-safe, but that code would be easy to fix.
Let's not introduce new RTL translation problems here.
Original answer (2014)
No, even though an alternative, based on a 'cat' of the htlp txt files, is suggested in "how do I get git to show command-line help in windows?".
There man.<tool>.cmd config introduced in 2008, allows to set a custom command, but msys shell isn't shipped with man.exe.
World's most overengineered workaround for this problem: use WSL
(that is, unless you already are a WSL user, in which case it's merely an ordinary workaround)
Install one of the linux distros via Windows Store
Go in and ensure it has the git package installed
From the Windows command line, bash -c 'git help fetch' etc.
Here's an alias for that last one:
[alias]
hep = "!f() { $SYSTEMROOT/System32/bash -c \"git help $1\"; }; f"
(And no you can't override git built-ins, but you can make a shell command to intercept and reroute help.)
I want to use Xcode 4's "Version Editor" view as my standard difftool for Git.
In other words, I want to be able to set this option:
git config --global diff.external <XCODE>
And have the diff open in Xcode's diff viewer (because it's cool).
Is this possible? How?
Sadly not possible. Here's hoping Apple changes that someday though.
I'm guessing you already know the following, but for the benefit of others who may not, you can use Apple's FileMerge application instead for a similar, albeit somewhat lesser, experience with a command like:
git difftool path/to/file
My git defaults to using FileMerge as the difftool, but you can configure it explicitly with:
git config --global diff.tool opendiff
(This stops git from listing the candidate tools every time too.) I also like to disable git's difftool pre-launch prompting:
git config --global difftool.prompt false
It is possible to configure git so that git diff will invoke FileMerge as well, or instead. (I prefer to just leave git diff the way it is myself.) If you want that you first need to create a shell script to map the appropriate arguments to opendiff:
#!/bin/sh
/usr/bin/opendiff "$2" "$5" -merge "$1"
and then run
git config --global diff.external /path/to/shell/script