summaryrefslogtreecommitdiff
path: root/Documentation
AgeCommit message (Collapse)AuthorFilesLines
2017-04-19Merge branch 'ah/diff-files-ours-theirs-doc'Libravatar Junio C Hamano1-0/+14
The diff options "--ours", "--theirs" exist for quite some time. But so far they were not documented. Now they are. * ah/diff-files-ours-theirs-doc: diff-files: document --ours etc.
2017-04-19Merge branch 'bc/object-id'Libravatar Junio C Hamano1-22/+22
Conversion from unsigned char [40] to struct object_id continues. * bc/object-id: Documentation: update and rename api-sha1-array.txt Rename sha1_array to oid_array Convert sha1_array_for_each_unique and for_each_abbrev to object_id Convert sha1_array_lookup to take struct object_id Convert remaining callers of sha1_array_lookup to object_id Make sha1_array_append take a struct object_id * sha1-array: convert internal storage for struct sha1_array to object_id builtin/pull: convert to struct object_id submodule: convert check_for_new_submodule_commits to object_id sha1_name: convert disambiguate_hint_fn to take object_id sha1_name: convert struct disambiguate_state to object_id test-sha1-array: convert most code to struct object_id parse-options-cb: convert sha1_array_append caller to struct object_id fsck: convert init_skiplist to struct object_id builtin/receive-pack: convert portions to struct object_id builtin/pull: convert portions to struct object_id builtin/diff: convert to struct object_id Convert GIT_SHA1_RAWSZ used for allocation to GIT_MAX_RAWSZ Convert GIT_SHA1_HEXSZ used for allocation to GIT_MAX_HEXSZ Define new hash-size constants for allocating memory
2017-04-19Merge branch 'sb/submodule-short-status'Libravatar Junio C Hamano1-0/+13
The output from "git status --short" has been extended to show various kinds of dirtyness in submodules differently; instead of to "M" for modified, 'm' and '?' can be shown to signal changes only to the working tree of the submodule but not the commit that is checked out. * sb/submodule-short-status: submodule.c: correctly handle nested submodules in is_submodule_modified short status: improve reporting for submodule changes submodule.c: stricter checking for submodules in is_submodule_modified submodule.c: port is_submodule_modified to use porcelain 2 submodule.c: convert is_submodule_modified to use strbuf_getwholeline submodule.c: factor out early loop termination in is_submodule_modified submodule.c: use argv_array in is_submodule_modified
2017-04-16Twelfth batch for 2.13Libravatar Junio C Hamano1-0/+16
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-16Merge branch 'qp/bisect-docfix'Libravatar Junio C Hamano1-1/+1
Doc update. * qp/bisect-docfix: git-bisect.txt: add missing word
2017-04-16Merge branch 'mm/ls-files-s-doc'Libravatar Junio C Hamano1-1/+1
Doc update. * mm/ls-files-s-doc: Documentation: document elements in "ls-files -s" output in order
2017-04-13diff-files: document --ours etc.Libravatar Andreas Heiduk1-0/+14
git-diff understands "--ours", "--theirs" and "--base" for files with conflicts. But so far they were not documented for the central diff command but only for diff-files. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-11Eleventh batch for 2.13Libravatar Junio C Hamano1-0/+14
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-11Merge branch 'ab/ref-filter-no-contains'Libravatar Junio C Hamano3-36/+68
"git tag/branch/for-each-ref" family of commands long allowed to filter the refs by "--contains X" (show only the refs that are descendants of X), "--merged X" (show only the refs that are ancestors of X), "--no-merged X" (show only the refs that are not ancestors of X). One curious omission, "--no-contains X" (show only the refs that are not descendants of X) has been added to them. * ab/ref-filter-no-contains: tag: add tests for --with and --without ref-filter: reflow recently changed branch/tag/for-each-ref docs ref-filter: add --no-contains option to tag/branch/for-each-ref tag: change --point-at to default to HEAD tag: implicitly supply --list given another list-like option tag: change misleading --list <pattern> documentation parse-options: add OPT_NONEG to the "contains" option tag: add more incompatibles mode tests for-each-ref: partly change <object> to <commit> in help tag tests: fix a typo in a test description tag: remove a TODO item from the test suite ref-filter: add test for --contains on a non-commit ref-filter: make combining --merged & --no-merged an error tag doc: reword --[no-]merged to talk about commits, not tips tag doc: split up the --[no-]merged documentation tag doc: move the description of --[no-]merged earlier
2017-04-01git-bisect.txt: add missing wordLibravatar Quentin Pradet1-1/+1
Signed-off-by: Quentin Pradet <quentin.pradet@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-01Documentation: document elements in "ls-files -s" output in orderLibravatar Mostyn Bramley-Moore1-1/+1
List the fields in order of appearance in the command output. Signed-off-by: Mostyn Bramley-Moore <mostyn@antipode.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-31Documentation: update and rename api-sha1-array.txtLibravatar brian m. carlson1-22/+22
Since the structure and functions have changed names, update the code examples and the documentation. Rename the file to match the new name of the API. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-30Tenth batch for 2.13Libravatar Junio C Hamano1-2/+64
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-30Merge branch 'ab/case-insensitive-upstream-and-push-marker'Libravatar Junio C Hamano1-1/+5
On many keyboards, typing "@{" involves holding down SHIFT key and one can easily end up with "@{Up..." when typing "@{upstream}". As the upstream/push keywords do not appear anywhere else in the syntax, we can safely accept them case insensitively without introducing ambiguity or confusion to solve this. * ab/case-insensitive-upstream-and-push-marker: rev-parse: match @{upstream}, @{u} and @{push} case-insensitively
2017-03-30Merge branch 'ab/doc-submitting'Libravatar Junio C Hamano1-3/+9
Doc update. * ab/doc-submitting: doc/SubmittingPatches: show how to get a CLI commit summary doc/SubmittingPatches: clarify the casing convention for "area: change..."
2017-03-30Merge branch 'bw/submodule-is-active'Libravatar Junio C Hamano3-8/+25
"what URL do we want to update this submodule?" and "are we interested in this submodule?" are split into two distinct concepts, and then the way used to express the latter got extended, paving a way to make it easier to manage a project with many submodules and make it possible to later extend use of multiple worktrees for a project with submodules. * bw/submodule-is-active: submodule add: respect submodule.active and submodule.<name>.active submodule--helper init: set submodule.<name>.active clone: teach --recurse-submodules to optionally take a pathspec submodule init: initialize active submodules submodule: decouple url and submodule interest submodule--helper clone: check for configured submodules using helper submodule sync: use submodule--helper is-active submodule sync: skip work for inactive submodules submodule status: use submodule--helper is-active submodule--helper: add is-active subcommand
2017-03-30Merge branch 'jc/merge-drop-old-syntax'Libravatar Junio C Hamano1-6/+1
Stop supporting "git merge <message> HEAD <commit>" syntax that has been deprecated since October 2007, and issues a deprecation warning message since v2.5.0. * jc/merge-drop-old-syntax: merge: drop 'git merge <message> HEAD <commit>' syntax
2017-03-29submodule.c: correctly handle nested submodules in is_submodule_modifiedLibravatar Stefan Beller1-0/+2
Suppose I have a superproject 'super', with two submodules 'super/sub' and 'super/sub1'. 'super/sub' itself contains a submodule 'super/sub/subsub'. Now suppose I run, from within 'super': echo hi >sub/subsub/stray-file echo hi >sub1/stray-file Currently we get would see the following output in git-status: git status --short m sub ? sub1 With this patch applied, the untracked file in the nested submodule is displayed as an untracked file on the 'super' level as well. git status --short ? sub ? sub1 This doesn't change the output of 'git status --porcelain=1' for nested submodules, because its output is always ' M' for either untracked files or local modifications no matter the nesting level of the submodule. 'git status --porcelain=2' is affected by this change in a nested submodule, though. Without this patch it would report the direct submodule as modified and having no untracked files. With this patch it would report untracked files. Chalk this up as a bug fix. This bug fix also affects the default output (non-short, non-porcelain) of git-status, which is not tested here. Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-29short status: improve reporting for submodule changesLibravatar Stefan Beller1-0/+11
If I add an untracked file to a submodule or modify a tracked file, currently "git status --short" treats the change in the same way as changes to the current HEAD of the submodule: $ git clone --quiet --recurse-submodules https://gerrit.googlesource.com/gerrit $ echo hello >gerrit/plugins/replication/stray-file $ sed -i -e 's/.*//' gerrit/plugins/replication/.mailmap $ git -C gerrit status --short M plugins/replication This is by analogy with ordinary files, where "M" represents a change that has not been added yet to the index. But this change cannot be added to the index without entering the submodule, "git add"-ing it, and running "git commit", so the analogy is counterproductive. Introduce new status letters " ?" and " m" for this. These are similar to the existing "??" and " M" but mean that the submodule (not the parent project) has new untracked files and modified files, respectively. The user can use "git add" and "git commit" from within the submodule to add them. Changes to the submodule's HEAD commit can be recorded in the index with a plain "git add -u" and are shown with " M", like today. To avoid excessive clutter, show at most one of " ?", " m", and " M" for the submodule. They represent increasing levels of change --- the last one that applies is shown (e.g., " m" if there are both modified files and untracked files in the submodule, or " M" if the submodule's HEAD has been modified and it has untracked files). While making these changes, we need to make sure to not break porcelain level 1, which shares code with "status --short". We only change "git status --short". Non-short "git status" and "git status --porcelain=2" already handle these cases by showing more detail: $ git -C gerrit status --porcelain=2 1 .M S.MU 160000 160000 160000 305c864db28eb0c77c8499bc04c87de3f849cf3c 305c864db28eb0c77c8499bc04c87de3f849cf3c plugins/replication $ git -C gerrit status [...] modified: plugins/replication (modified content, untracked content) Scripts caring about these distinctions should use --porcelain=2. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-28Ninth batch for 2.13Libravatar Junio C Hamano1-30/+24
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-28Sync with 'maint'Libravatar Junio C Hamano1-0/+57
2017-03-28Merge branch 'jh/memihash-opt'Libravatar Junio C Hamano1-0/+22
The name-hash used for detecting paths that are different only in cases (which matter on case insensitive filesystems) has been optimized to take advantage of multi-threading when it makes sense. * jh/memihash-opt: name-hash: add test-lazy-init-name-hash to .gitignore name-hash: add perf test for lazy_init_name_hash name-hash: add test-lazy-init-name-hash name-hash: perf improvement for lazy_init_name_hash hashmap: document memihash_cont, hashmap_disallow_rehash api hashmap: add disallow_rehash setting hashmap: allow memihash computation to be continued name-hash: specify initial size for istate.dir_hash table
2017-03-28Merge branch 'ab/branch-list-doc'Libravatar Junio C Hamano1-2/+7
Doc update. * ab/branch-list-doc: branch doc: update description for `--list` branch doc: change `git branch <pattern>` to use `<branchname>`
2017-03-28Merge branch 'sb/checkout-recurse-submodules'Libravatar Junio C Hamano2-0/+13
"git checkout" is taught the "--recurse-submodules" option. * sb/checkout-recurse-submodules: builtin/read-tree: add --recurse-submodules switch builtin/checkout: add --recurse-submodules switch entry.c: create submodules when interesting unpack-trees: check if we can perform the operation for submodules unpack-trees: pass old oid to verify_clean_submodule update submodules: add submodule_move_head submodule.c: get_super_prefix_or_empty update submodules: move up prepare_submodule_repo_env submodules: introduce check to see whether to touch a submodule update submodules: add a config option to determine if submodules are updated update submodules: add submodule config parsing make is_submodule_populated gently lib-submodule-update.sh: define tests for recursing into submodules lib-submodule-update.sh: replace sha1 by hash lib-submodule-update: teach test_submodule_content the -C <dir> flag lib-submodule-update.sh: do not use ./. as submodule remote lib-submodule-update.sh: reorder create_lib_submodule_repo submodule--helper.c: remove duplicate code connect_work_tree_and_git_dir: safely create leading directories
2017-03-28Prepare for 2.12.3Libravatar Junio C Hamano1-0/+57
2017-03-28Merge branch 'km/config-grammofix' into maintLibravatar Junio C Hamano1-3/+3
Doc update. * km/config-grammofix: doc/config: grammar fixes for core.{editor,commentChar}
2017-03-28Merge branch 'dp/filter-branch-prune-empty' into maintLibravatar Junio C Hamano1-8/+6
"git filter-branch --prune-empty" drops a single-parent commit that becomes a no-op, but did not drop a root commit whose tree is empty. * dp/filter-branch-prune-empty: p7000: add test for filter-branch with --prune-empty filter-branch: fix --prune-empty on parentless commits t7003: ensure --prune-empty removes entire branch when applicable t7003: ensure --prune-empty can prune root commit
2017-03-27Eighth batch for 2.13Libravatar Junio C Hamano1-0/+22
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-27Merge branch 'km/config-grammofix'Libravatar Junio C Hamano1-3/+3
Doc update. * km/config-grammofix: doc/config: grammar fixes for core.{editor,commentChar}
2017-03-27Merge branch 'sb/describe-broken'Libravatar Junio C Hamano1-3/+8
"git describe --dirty" dies when it cannot be determined if the state in the working tree matches that of HEAD (e.g. broken repository or broken submodule). The command learned a new option "git describe --broken" to give "$name-broken" (where $name is the description of HEAD) in such a case. * sb/describe-broken: builtin/describe: introduce --broken flag
2017-03-27Merge branch 'sb/push-options-via-transport'Libravatar Junio C Hamano1-0/+6
Recently we started passing the "--push-options" through the external remote helper interface; now the "smart HTTP" remote helper understands what to do with the passed information. * sb/push-options-via-transport: remote-curl: allow push options send-pack: send push options correctly in stateless-rpc case
2017-03-27rev-parse: match @{upstream}, @{u} and @{push} case-insensitivelyLibravatar Ævar Arnfjörð Bjarmason1-1/+5
Change the revision parsing logic to match @{upstream}, @{u} & @{push} case-insensitively. Before this change supplying anything except the lower-case forms emits an "unknown revision or path not in the working tree" error. This change makes upper-case & mixed-case versions equivalent to the lower-case versions. The use-case for this is being able to hold the shift key down while typing @{u} on certain keyboard layouts, which makes the sequence easier to type, and reduces cases where git throws an error at the user where it could do what he means instead. These suffixes now join various other suffixes & special syntax documented in gitrevisions(7) that matches case-insensitively. A table showing the status of the various forms documented there before & after this patch is shown below. The key for the table is: - CI = Case Insensitive - CIP = Case Insensitive Possible (without ambiguities) - AG = Accepts Garbage (.e.g. @{./.4.minutes./.}) Before this change: |----------------+-----+------+-----| | What? | CI? | CIP? | AG? | |----------------+-----+------+-----| | @{<date>} | Y | Y | Y | | @{upstream} | N | Y | N | | @{push} | N | Y | N | |----------------+-----+------+-----| After it: |----------------+-----+------+-----| | What? | CI? | CIP? | AG? | |----------------+-----+------+-----| | @{<date>} | Y | Y | Y | | @{upstream} | Y | Y | N | | @{push} | Y | Y | N | |----------------+-----+------+-----| The ^{<type>} suffix is not made case-insensitive, because other places that take <type> like "cat-file -t <type>" do want them case sensitively (after all we never declared that type names are case insensitive). Allowing case-insensitive typename only with this syntax will make the resulting Git as a whole inconsistent. This change was independently authored to scratch a longtime itch, but when I was about to submit it I discovered that a similar patch had been submitted unsuccessfully before by Conrad Irwin in August 2011 as "rev-parse: Allow @{U} as a synonym for @{u}" (<1313287071-7851-1-git-send-email-conrad.irwin@gmail.com>). The tests for this patch are more exhaustive than in the 2011 submission. The starting point for them was to first change the code to only support upper-case versions of the existing words, seeing what broke, and amending the breaking tests to check upper case & mixed case as appropriate, and where not redundant to other similar tests. The implementation itself is equivalent. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-26doc/SubmittingPatches: show how to get a CLI commit summaryLibravatar Ævar Arnfjörð Bjarmason1-1/+2
Amend the section which describes how to get a commit summary to show how do to that with "git show", currently the documentation only shows how to do that with gitk. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24Sync with 2.12.2Libravatar Junio C Hamano2-1/+24
2017-03-24Seventh batch for 2.13Libravatar Junio C Hamano1-9/+29
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24Merge branch 'dl/credential-cache-socket-in-xdg-cache'Libravatar Junio C Hamano1-4/+7
The default location "~/.git-credential-cache/socket" for the socket used to communicate with the credential-cache daemon has been moved to "~/.cache/git/credential/socket". * dl/credential-cache-socket-in-xdg-cache: credential-cache: add tests for XDG functionality credential-cache: use XDG_CACHE_HOME for socket path.c: add xdg_cache_home
2017-03-24Git 2.12.2Libravatar Junio C Hamano2-1/+24
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24Merge branch 'ab/doc-no-option-notation-fix' into maintLibravatar Junio C Hamano2-2/+2
Doc fix. * ab/doc-no-option-notation-fix: doc: change erroneous --[no]-whatever into --[no-]whatever
2017-03-24Merge branch 'ab/push-default-doc-fix' into maintLibravatar Junio C Hamano1-0/+2
Doc fix. * ab/push-default-doc-fix: push: mention "push.default=tracking" in the documentation
2017-03-24Merge branch 'nd/commit-hook-doc-fix' into maintLibravatar Junio C Hamano1-1/+1
Doc fix. * nd/commit-hook-doc-fix: git-commit.txt: list post-rewrite in HOOKS section
2017-03-24ref-filter: reflow recently changed branch/tag/for-each-ref docsLibravatar Ævar Arnfjörð Bjarmason2-10/+12
Reflow the recently changed branch/tag-for-each-ref documentation. This change shows no changes under --word-diff, except the innocuous change of moving git-tag.txt's "[--sort=<key>]" around slightly. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24ref-filter: add --no-contains option to tag/branch/for-each-refLibravatar Ævar Arnfjörð Bjarmason3-6/+22
Change the tag, branch & for-each-ref commands to have a --no-contains option in addition to their longstanding --contains options. This allows for finding the last-good rollout tag given a known-bad <commit>. Given a hypothetically bad commit cf5c7253e0, the git version to revert to can be found with this hacky two-liner: (git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') | sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10 With this new --no-contains option the same can be achieved with: git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10 As the filtering machinery is shared between the tag, branch & for-each-ref commands, implement this for those commands too. A practical use for this with "branch" is e.g. finding branches which were branched off between v2.8.0 and v2.10.0: git branch --contains v2.8.0 --no-contains v2.10.0 The "describe" command also has a --contains option, but its semantics are unrelated to what tag/branch/for-each-ref use --contains for. A --no-contains option for "describe" wouldn't make any sense, other than being exactly equivalent to not supplying --contains at all, which would be confusing at best. Add a --without option to "tag" as an alias for --no-contains, for consistency with --with and --contains. The --with option is undocumented, and possibly the only user of it is Junio (<xmqqefy71iej.fsf@gitster.mtv.corp.google.com>). But it's trivial to support, so let's do that. The additions to the the test suite are inverse copies of the corresponding --contains tests. With this change --no-contains for tag, branch & for-each-ref is just as well tested as the existing --contains option. In addition to those tests, add a test for "tag" which asserts that --no-contains won't find tree/blob tags, which is slightly unintuitive, but consistent with how --contains works & is documented. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24tag: change --point-at to default to HEADLibravatar Ævar Arnfjörð Bjarmason1-1/+2
Change the --points-at option to default to HEAD for consistency with its siblings --contains, --merged etc. which default to HEAD. Previously we'd get: $ git tag --points-at 2>&1 | head -n 1 error: option `points-at' requires a value This changes behavior added in commit ae7706b9ac (tag: add --points-at list option, 2012-02-08). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24tag: implicitly supply --list given another list-like optionLibravatar Ævar Arnfjörð Bjarmason1-6/+11
Change the "tag" command to implicitly turn on its --list mode when provided with a list-like option such as --contains, --points-at etc. This is for consistency with how "branch" works. When "branch" is given a list-like option, such as --contains, it implicitly provides --list. Before this change "tag" would error out on those sorts of invocations. I.e. while both of these worked for "branch": git branch --contains v2.8.0 <pattern> git branch --list --contains v2.8.0 <pattern> Only the latter form worked for "tag": git tag --contains v2.8.0 '*rc*' git tag --list --contains v2.8.0 '*rc*' Now "tag", like "branch", will implicitly supply --list when a list-like option is provided, and no other conflicting non-list options (such as -d) are present on the command-line. Spelunking through the history via: git log --reverse -p -G'only allowed with' -- '*builtin*tag*c' Reveals that there was no good reason for not allowing this in the first place. The --contains option added in 32c35cfb1e ("git-tag: Add --contains option", 2009-01-26) made this an error. All the other subsequent list-like options that were added copied its pattern of making this usage an error. The only tests that break as a result of this change are tests that were explicitly checking that this "branch-like" usage wasn't permitted. Change those failing tests to check that this invocation mode is permitted, add extra tests for the list-like options we weren't testing, and tests to ensure that e.g. we don't toggle the list mode in the presence of other conflicting non-list options. With this change errors messages such as "--contains option is only allowed with -l" don't make sense anymore, since options like --contain turn on -l. Instead we error out when list-like options such as --contain are used in conjunction with conflicting options such as -d or -v. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24tag: change misleading --list <pattern> documentationLibravatar Ævar Arnfjörð Bjarmason1-7/+8
Change the documentation for --list so that it's described as a toggle, not as an option that takes a <pattern> as an argument. Junio initially documented this in b867c7c23a ("git-tag: -l to list tags (usability).", 2006-02-17), but later Jeff King changed "tag" to accept multiple patterns in 588d0e834b ("tag: accept multiple patterns for --list", 2011-06-20). However, documenting this as "-l <pattern>" was never correct, as these both worked before Jeff's change: git tag -l 'v*' git tag 'v*' -l One would expect an option that was documented like that to only accept: git tag --list git tag --list 'v*rc*' And after Jeff's change, one that took multiple patterns: git tag --list 'v*rc*' --list '*2.8*' But since it's actually a toggle all of these work as well, and produce identical output to the last example above: git tag --list 'v*rc*' '*2.8*' git tag --list 'v*rc*' '*2.8*' --list --list --list git tag --list 'v*rc*' '*2.8*' --list -l --list -l --list Now the documentation is more in tune with how the "branch" command describes its --list option since commit cddd127b9a ("branch: introduce --list option", 2011-08-28). Change the test suite to assert that these invocations work for the cases that weren't already being tested for. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24branch doc: update description for `--list`Libravatar Junio C Hamano1-2/+7
The paragraph begins with a sample command line `git branch <name>` that has nothing to do with the option being described. Remove it, but use the space to instead show that multiple patterns can be given. Also mention the unfortunate `-l` that can be easily confused with it. Signed-off-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23branch doc: change `git branch <pattern>` to use `<branchname>`Libravatar Ævar Arnfjörð Bjarmason1-1/+1
Change an example for `git branch <pattern>` to say `git branch <branchname>` to be consistent with the synopsis. This changes documentation added in d8d33736b5 ("branch: allow pattern arguments", 2011-08-28). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23doc/config: grammar fixes for core.{editor,commentChar}Libravatar Kyle Meyer1-3/+3
Signed-off-by: Kyle Meyer <kyle@kyleam.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23hashmap: document memihash_cont, hashmap_disallow_rehash apiLibravatar Jeff Hostetler1-0/+22
Document memihash_cont() and hashmap_disallow_rehash() in Documentation/technical/api-hashmap.txt. Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-22remote-curl: allow push optionsLibravatar Brandon Williams1-0/+6
Teach remote-curl to understand push options and to be able to convey them across HTTP. Signed-off-by: Brandon Williams <bmwill@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>