зеркало из https://github.com/microsoft/git.git
Merge branch 'maint'
* maint: contrib/thunderbird-patch-inline: do not require bash to run the script t8001: check the exit status of the command being tested strbuf.h: remove a tad stale docs-in-comment and reference api-doc instead Typos: t/README Documentation/config.txt: make truth value of numbers more explicit git-pack-objects.txt: fix grammatical errors parse-remote: replace unnecessary sed invocation
This commit is contained in:
Коммит
17a0299807
|
@ -62,7 +62,7 @@ Internal whitespace within a variable value is retained verbatim.
|
|||
|
||||
The values following the equals sign in variable assign are all either
|
||||
a string, an integer, or a boolean. Boolean values may be given as yes/no,
|
||||
0/1, true/false or on/off. Case is not significant in boolean values, when
|
||||
1/0, true/false or on/off. Case is not significant in boolean values, when
|
||||
converting value to the canonical form using '--bool' type specifier;
|
||||
'git config' will ensure that the output is "true" or "false".
|
||||
|
||||
|
|
|
@ -190,9 +190,9 @@ self-contained. Use `git index-pack --fix-thin`
|
|||
(see linkgit:git-index-pack[1]) to restore the self-contained property.
|
||||
|
||||
--delta-base-offset::
|
||||
A packed archive can express base object of a delta as
|
||||
either 20-byte object name or as an offset in the
|
||||
stream, but older version of git does not understand the
|
||||
A packed archive can express the base object of a delta as
|
||||
either a 20-byte object name or as an offset in the
|
||||
stream, but older versions of git don't understand the
|
||||
latter. By default, 'git pack-objects' only uses the
|
||||
former format for better compatibility. This option
|
||||
allows the command to use the latter format for
|
||||
|
|
|
@ -1,8 +1,8 @@
|
|||
#!/bin/bash
|
||||
#!/bin/sh
|
||||
# Copyright 2008 Lukas Sandström <luksan@gmail.com>
|
||||
#
|
||||
# AppendPatch - A script to be used together with ExternalEditor
|
||||
# for Mozilla Thunderbird to properly include pathes inline i e-mails.
|
||||
# for Mozilla Thunderbird to properly include patches inline in e-mails.
|
||||
|
||||
# ExternalEditor can be downloaded at http://globs.org/articles.php?lng=en&pg=2
|
||||
|
||||
|
|
|
@ -5,7 +5,8 @@
|
|||
GIT_DIR=$(git rev-parse -q --git-dir) || :;
|
||||
|
||||
get_default_remote () {
|
||||
curr_branch=$(git symbolic-ref -q HEAD | sed -e 's|^refs/heads/||')
|
||||
curr_branch=$(git symbolic-ref -q HEAD)
|
||||
curr_branch="${cur_branch#refs/heads/}"
|
||||
origin=$(git config --get "branch.$curr_branch.remote")
|
||||
echo ${origin:-origin}
|
||||
}
|
||||
|
|
37
strbuf.h
37
strbuf.h
|
@ -1,42 +1,7 @@
|
|||
#ifndef STRBUF_H
|
||||
#define STRBUF_H
|
||||
|
||||
/*
|
||||
* Strbuf's can be use in many ways: as a byte array, or to store arbitrary
|
||||
* long, overflow safe strings.
|
||||
*
|
||||
* Strbufs has some invariants that are very important to keep in mind:
|
||||
*
|
||||
* 1. the ->buf member is always malloc-ed, hence strbuf's can be used to
|
||||
* build complex strings/buffers whose final size isn't easily known.
|
||||
*
|
||||
* It is NOT legal to copy the ->buf pointer away.
|
||||
* `strbuf_detach' is the operation that detaches a buffer from its shell
|
||||
* while keeping the shell valid wrt its invariants.
|
||||
*
|
||||
* 2. the ->buf member is a byte array that has at least ->len + 1 bytes
|
||||
* allocated. The extra byte is used to store a '\0', allowing the ->buf
|
||||
* member to be a valid C-string. Every strbuf function ensures this
|
||||
* invariant is preserved.
|
||||
*
|
||||
* Note that it is OK to "play" with the buffer directly if you work it
|
||||
* that way:
|
||||
*
|
||||
* strbuf_grow(sb, SOME_SIZE);
|
||||
* ... Here, the memory array starting at sb->buf, and of length
|
||||
* ... strbuf_avail(sb) is all yours, and you are sure that
|
||||
* ... strbuf_avail(sb) is at least SOME_SIZE.
|
||||
* strbuf_setlen(sb, sb->len + SOME_OTHER_SIZE);
|
||||
*
|
||||
* Of course, SOME_OTHER_SIZE must be smaller or equal to strbuf_avail(sb).
|
||||
*
|
||||
* Doing so is safe, though if it has to be done in many places, adding the
|
||||
* missing API to the strbuf module is the way to go.
|
||||
*
|
||||
* XXX: do _not_ assume that the area that is yours is of size ->alloc - 1
|
||||
* even if it's true in the current implementation. Alloc is somehow a
|
||||
* "private" member that should not be messed with.
|
||||
*/
|
||||
/* See Documentation/technical/api-strbuf.txt */
|
||||
|
||||
#include <assert.h>
|
||||
|
||||
|
|
9
t/README
9
t/README
|
@ -201,7 +201,7 @@ we are testing.
|
|||
If you create files under t/ directory (i.e. here) that is not
|
||||
the top-level test script, never name the file to match the above
|
||||
pattern. The Makefile here considers all such files as the
|
||||
top-level test script and tries to run all of them. A care is
|
||||
top-level test script and tries to run all of them. Care is
|
||||
especially needed if you are creating a common test library
|
||||
file, similar to test-lib.sh, because such a library file may
|
||||
not be suitable for standalone execution.
|
||||
|
@ -285,9 +285,8 @@ Do:
|
|||
- Check the test coverage for your tests. See the "Test coverage"
|
||||
below.
|
||||
|
||||
Don't blindly follow test coverage metrics, they're a good way to
|
||||
spot if you've missed something. If a new function you added
|
||||
doesn't have any coverage you're probably doing something wrong,
|
||||
Don't blindly follow test coverage metrics; if a new function you added
|
||||
doesn't have any coverage, then you're probably doing something wrong,
|
||||
but having 100% coverage doesn't necessarily mean that you tested
|
||||
everything.
|
||||
|
||||
|
@ -431,7 +430,7 @@ library for your script to use.
|
|||
- test_tick
|
||||
|
||||
Make commit and tag names consistent by setting the author and
|
||||
committer times to defined stated. Subsequent calls will
|
||||
committer times to defined state. Subsequent calls will
|
||||
advance the times by a fixed amount.
|
||||
|
||||
- test_commit <message> [<filename> [<contents>]]
|
||||
|
|
|
@ -6,10 +6,11 @@ test_description='git annotate'
|
|||
PROG='git annotate'
|
||||
. "$TEST_DIRECTORY"/annotate-tests.sh
|
||||
|
||||
test_expect_success \
|
||||
'Annotating an old revision works' \
|
||||
'[ $(git annotate file master | awk "{print \$3}" | grep -c "^A$") -eq 2 ] && \
|
||||
[ $(git annotate file master | awk "{print \$3}" | grep -c "^B$") -eq 2 ]'
|
||||
|
||||
test_expect_success 'Annotating an old revision works' '
|
||||
git annotate file master >result &&
|
||||
awk "{ print \$3; }" <result >authors &&
|
||||
test 2 = $(grep A <authors | wc -l) &&
|
||||
test 2 = $(grep B <authors | wc -l)
|
||||
'
|
||||
|
||||
test_done
|
||||
|
|
Загрузка…
Ссылка в новой задаче