that we are running
a self-test, so that various pieces in test-lib.sh can react to keep
the output stable.
Signed-off-by: Junio C Hamano
---
t/t-basic.sh | 4
t/test-lib.sh| 8
2 files changed, 12 insertions(+)
diff --git a/t/t-basic.sh b/t/t-basic.sh
index 850f651e4e
Eric Sunshine writes:
> On Tue, Sep 18, 2018 at 1:48 AM Ævar Arnfjörð Bjarmason
> wrote:
>> "Work the same" is incorrect and needs to be "Works the same
>> way". Fixes grammar in document anion I added in the recently landed
>
> I, too, find those "document anions" problematic. Perhaps the
>
KES writes:
> PS. for `git push --force` there is alternative: --force-with-lease
> Is there something similar to --force-with-lease but for `git pull -v
> --rebase`?
Curious.
For "push", you are competing with the other pushers who want to
update the repository over there, and there is need
Ramsay Jones writes:
> Commit ef3ca95475 ("Add missing includes and forward declarations",
> 2018-08-15) resulted from the author employing a manual method to
> create a C file consisting of a pair of pre-processor #include
> lines (for 'git-compat-util.h' and a given toplevel header), and
>
Shulhan writes:
> For someone who use editor that display trailing white spaces, issuing
> interactive rebase will print two empty lines at the end of rebase with the
> last line contains tab,
>
> # However, if you remove everything, the rebase will be aborted.
> #
> #\t
> # Note that
"brian m. carlson" writes:
> I think "make style" and the EditorConfig file are complementary. "make
> style" autoformats code into a diff. I agree that if we always used
> clang-format to format code, then this would be a non-issue in the
> EditorConfig file, since we'd just tell people to
Frederick Eaton writes:
> When I read this man page I couldn't figure out what kind of input it
> was referring to, or how input was being put into columns, or where I
> should look for the syntax of the --mode option.
>
> Signed-off-by: Frederick Eaton
> ---
> Documentation/git-column.txt |
Frederick Eaton writes:
> Is it a CPU architecture? Is it Arch Linux? If you search for "arch
> repository", nothing relevant comes up. Let's call it GNU Arch so
> people can find it with search engines.
>
> Signed-off-by: Frederick Eaton
> ---
> Documentation/git-archimport.txt | 5 +++--
> 1
.
> By the way for some reason git-contacts shows more names when I run it
> on the patch hash than when I give it the patch name:
>
> $ ./contrib/contacts/git-contacts 222580cb60ee64f7b81fed64ec8fbfc81952557f
> Sébastien Guimmara
> Nguyễn Thái Ngọc Duy
> Eric Sunshine
> Jun
Junio C Hamano writes:
> SZEDER Gábor writes:
>
>>> While inspecting this code, I realized that the final test for
>>> 'commit_contains --tag' is silently dropping the '--tag' argument.
>>> It should be quoted to include both.
>>
>> Nit: while quotin
SZEDER Gábor writes:
>> While inspecting this code, I realized that the final test for
>> 'commit_contains --tag' is silently dropping the '--tag' argument.
>> It should be quoted to include both.
>
> Nit: while quoting the function's arguments does fix the issue, it
> leaves the tests prone to
SZEDER Gábor writes:
> it appears that this patch (and its previous versions as well) is
> responsible for triggering occasional test failures in
> 't7814-grep-recurse-submodules.sh', more frequently, about once in
> every ten runs, on macOS on Travis CI, less frequently, about once in
> a
Nguyễn Thái Ngọc Duy writes:
> Commit b0db704652 (pathspec: allow querying for attributes -
> 2017-03-13) adds new pathspec magic 'attr' but only with
> match_pathspec(). "git add" has some pathspec related code that still
> does not know about 'attr' and will bail out:
>
> $ git add
Matthew DeVore writes:
> Yes, it's probably better to add a point about that. Here is the new
> documentation after applying your suggestions:
>
> - If a piped sequence which spans multiple lines, put each statement
>on a separate line and put pipes on the end of each line, rather
>than
"brian m. carlson" writes:
> To make automatically configuring one's editor easier, provide an
> EditorConfig file. This is an INI-style configuration file that can be
> used to specify editor settings and can be understood by a wide variety
> of editors. Some editors include this support
Jeff King writes:
>> -cat >expect_cookies.txt <> +cat
> This can be spelled:
>
> sort >expect_cookies.txt <
> can't it? Then we do not even incur the extra process. :)
Yeah, true. Running cat only to feed a pipe with contents of a
single file or the here-doc is an
Junio C Hamano writes:
> The tip of 'next' hasn't been rewound yet, but the states of many
> topics that were marked to "Cook in 'next'" read "Will merge to
> 'master'" now. I'll probably start merging a handful of topics that
> have been in 'next' down
or cookies", 2018-08-28)
[jc: Also use a part of the patch by Thomas Gummerer that sorts the
expected output, which makes it easier to maintain.]
Signed-off-by: Todd Zullinger
Helped-by: Thomas Gummerer
Signed-off-by: Junio C Hamano
---
t/t5551-http-fetch-smart.sh | 4 ++--
1 file changed,
Duy Nguyen writes:
>> diff --git a/read-cache.c b/read-cache.c
>> index 858935f123..b203eebb44 100644
>> --- a/read-cache.c
>> +++ b/read-cache.c
>> @@ -23,6 +23,10 @@
>> #include "split-index.h"
>> #include "utf8.h"
>> #include "fsmonitor.h"
>> +#ifndef NO_PTHREADS
>> +#include
>> +#include
Derrick Stolee writes:
> Thanks for catching this, Ramsay. Sorry for the mistake.
>
> ds/multi-pack-verify is currently queued for 'next', so I wasn't
> planning on sending another version.
Marked for 'next' does not mean we cannot touch it. It merely means
"so far no issue that requires a
Derrick Stolee writes:
> ds/multi-pack-verify is currently queued for 'next', so I wasn't
> planning on sending another version.
>
> Junio, could you add this commit to the tip, or squash it into
> 64cbf3df2 "multi-pack-index: add 'verify' verb"?
I think it makes sense to queue this on top.
Thomas Gummerer writes:
> In t5551 we check that we save cookies correctly to a file when
> http.cookiefile and http.savecookies are set. To do so we create an
> expect file that expects the cookies in a certain order.
>
> However after e2ef8d6fa ("cookies: support creation-time attribute for
>
Jonathan Nieder writes:
> I'd rather that we revert this change altogether. I have nothing
> against a convenient command to do this kind of non build related
> cleanup, but it shouldn't be spelled as "make clean".
OK, let's do this for now as I wanted to merge the remainder to
'master' today.
Jonathan Nieder writes:
>> +'$(SHELL_PATH_SQ)' ./doc-diff --clean
>
> This means I need a copy of git in order to run "make clean". That
> was never required before. It makes bootstrapping difficult --- do we
> really need it?
Gahh, you are absolutely right. Also "doc-diff --clean", if I
Duy Nguyen writes:
> On Mon, Sep 17, 2018 at 7:09 PM Junio C Hamano wrote:
>> ...
>> On the other hand, if I am keeping some change that should never be
>> in a commit in the working tree file, and building the contents in
>> the index using "add -p" t
Duy Nguyen writes:
> On Mon, Sep 17, 2018 at 6:25 PM Junio C Hamano wrote:
>>
>> Nguyễn Thái Ngọc Duy writes:
>>
>> > This function calls do_diff_cache() which eventually needs to set this
>> > "istate" to unpack_options->src_index (*)
Duy Nguyen writes:
> I get annoyed by the "ignoring unknown extension xxx" messages while
> testing though (not just this extension) and I think it will be the
> same for other git implementations. But perhaps other implementations
> just silently drop the extension. Most of the extensions we
Derrick Stolee writes:
>> Replaced with a newer version.
>
> I think this has been the same note for a few weeks now. What does it
> mean? Did I send a new version out that you haven't picked up?
It just means that I didn't bother to look at the current status
message for the topic that had
Jeff King writes:
>> > What's the donness of this one?
>> > cf. <20180717201348.gd26...@sigill.intra.peff.net>
>>
>> This topic has stayed in 'pu' for a long time. I thought it was
>> concluded that this was a good change? Jeff, Jonathan?
>
> I read over the thread again. I don't think I
Duy Nguyen writes:
> But it _is_ available now. If you need it, you write the extension
> out.
Are you arguing for making it omitted when it is not needed (e.g.
small enough index file)? IOW, did you mean "If you do not need it,
you do not write it out" by the above?
I do not think overhead
Duy Nguyen writes:
> On Sat, Sep 15, 2018 at 12:22 PM Duy Nguyen wrote:
>> Wait there's no way to disable this parallel reading? Does not sound
>> right. And if ordinary numbers mean the number of threads then 0
>> should mean no threading. Auto detection could have a new keyword,
>> like
Nguyễn Thái Ngọc Duy writes:
> This is about mixing "git add -p" and "git commit -a" (or "git commit
> ") where you may accidentally lose staged changes. After the
> discussion with Jonathan, I'm going with a bit different approach than
> v1, this behavior now becomes default, and if the user
David Aguilar writes:
> While I do see the utility, it would be just as easy to configure a 2nd
> and 3rd variant of the same difftool and use those as needed instead.
>
> "git difftool -t ccdiff2" or "-t ccdiff3" is the simplest, and there's
> nothing stopping the user from creating aliases to
Nguyễn Thái Ngọc Duy writes:
> The current naming convention for 'struct repository *' is 'r' for
> temporary variables or arguments. I did not notice this. Since we're
> updating blame.c again in the next patch, let's fix this.
It is likely that we end up having to refer to an in-core
Nguyễn Thái Ngọc Duy writes:
> This function calls do_diff_cache() which eventually needs to set this
> "istate" to unpack_options->src_index (*). This is an unfortunate fact
> that unpack_trees() _will_ destroy src_index so we can't really pass a
Wasn't the whole point of introducing
Tim Schumacher writes:
> On 08.09.18 15:28, Duy Nguyen wrote:
>> On Sat, Sep 8, 2018 at 12:44 AM Tim Schumacher wrote:
>>> + /*
>>> +* It could be an alias -- this works around the insanity
>>> * of overriding "git log" with "git show" by having
Antonio Ospite writes:
> I did send a v4 addressing this:
> https://public-inbox.org/git/20180824132951.8000-1-...@ao2.it/
>
> In case you missed it I might as well send a v5 with some minor
> cosmetic touches suggested by Ævar:
> https://public-inbox.org/git/87wosfesxl@evledraar.gmail.com/
"brian m. carlson" writes:
> On Fri, Sep 14, 2018 at 02:56:36PM -0700, Junio C Hamano wrote:
>> * bc/hash-independent-tests (2018-09-13) 12 commits
>> - t5318: use test_oid for HASH_LEN
>> - t1407: make hash size independent
>> - t1406: make hash-size in
Jeff King writes:
> (Also, to be clear, this is all _only_ about "Git Cola". The "git-cola"
> command is explicitly OK in the policy because that's how commands
> work).
These match my understanding. Thanks for spelling them out. That
project is an example of being a good ecosystem citizen
"Robert P. J. Day" writes:
> is there a command (git fsck?) that would display exclusively
> objects in the object store corresponding to objects that are suddenly
> unreferenced due to the removal of a remote?
fsck gives you dangling ones (and can be told to give you
unreachable ones, too)
Matthew DeVore writes:
> As requested in:
> https://public-inbox.org/git/xmqqmuskas3a@gitster-ct.c.googlers.com/
> this patchset corrects ordering of test_cmp arguments and | placement.
>
> The request didn't explicitly state whether all the tests should be cleaned
> up,
> but I did clean
Junio C Hamano writes:
> Ben Peart writes:
>
>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>> index 653688c067..397eb71578 100644
>> --- a/t/test-lib.sh
>> +++ b/t/test-lib.sh
>> @@ -134,9 +134,9 @@ export EDITOR
>> GIT_TRACE_BARE=1
>
Ben Peart writes:
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 653688c067..397eb71578 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -134,9 +134,9 @@ export EDITOR
> GIT_TRACE_BARE=1
> export GIT_TRACE_BARE
>
> -if test -n "${TEST_GIT_INDEX_VERSION:+isset}"
> +if test -n
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The tip of 'next' hasn't been
Jonathan Nieder writes:
> Maybe something like:
>
> preload-index: use git_env_bool() not getenv() for customization
>
> GIT_FORCE_PRELOAD_TEST is only checked for presence by using getenv().
> Use git_env_bool() instead so that GIT_FORCE_PRELOAD_TEST=false can
> work as
Ben Peart writes:
> The difference here is that core.fsmonitor isn't a boolean value. It
> is a string to a command that is executed so it can't be moved over to
> get_env_bool().
Ah, of course ;-)
Then please take the following as a review comment for 4/4; checking
if each getenv(VAR) should
Junio C Hamano writes:
>> diff --git a/t/t5616-partial-clone.sh b/t/t5616-partial-clone.sh
>> index bbbe7537d..8eeb85fbc 100755
>> --- a/t/t5616-partial-clone.sh
>> +++ b/t/t5616-partial-clone.sh
>> ...
>
> Break line after pipe "|", not before, and
Matthew DeVore writes:
> diff --git a/list-objects-filter-options.c b/list-objects-filter-options.c
> index c0e2bd6a0..14f251de4 100644
> --- a/list-objects-filter-options.c
> +++ b/list-objects-filter-options.c
> @@ -50,6 +50,20 @@ static int gently_parse_list_objects_filter(
>
Matthew DeVore writes:
> Currently, list-objects.c incorrectly treats all root trees of commits
> as USER_GIVEN. Also, it would be easier to mark objects that are
> non-user-given instead of user-given, since the places in the code
> where we access an object through a reference are more obvious
Ben Peart writes:
> diff --git a/config.c b/config.c
> index 3461993f0a..3555c63f28 100644
> --- a/config.c
> +++ b/config.c
> @@ -2278,7 +2278,7 @@ int git_config_get_max_percent_split_change(void)
> int git_config_get_fsmonitor(void)
> {
> if (git_config_get_pathname("core.fsmonitor",
Junio C Hamano writes:
> Ben Peart writes:
>
>> +if test -n "$GIT_FSMONITOR_TEST"
>> +then
>> +if test -n "$GIT_TEST_FSMONITOR"
>> +then
>> +echo "warning: the GIT_FSMONITOR_TEST variable has been renamed
>&
Ben Peart writes:
> +if test -n "$GIT_FSMONITOR_TEST"
> +then
> + if test -n "$GIT_TEST_FSMONITOR"
> + then
> + echo "warning: the GIT_FSMONITOR_TEST variable has been renamed
> to GIT_TEST_FSMONITOR"
> + else
> + echo "error: the GIT_FSMONITOR_TEST variable
Shulhan writes:
> if source is run successfully before I know the patch was correct, as
> the "t/README" said,
>
> Running Tests
> -
>
> The easiest way to run tests is to say "make". This runs all
> the tests.
t/README says that it is sufficient to run "make" to perform
Ben Peart writes:
>> I think it is OK to make it error only if the old one is set without
>> the new one. Then people can have _both_ set to the same value
>> during the period in which the topic sails through pu down to next
>> down to master, after seeing an failure once while building and
>>
Jonathan Nieder writes:
>> I think though that instead of doing setlocale() it would be better to
>> pass some flag saying we're operating in a machine-readable mode, and
>> then we'd (as part of the protocol defintion) say we're going to emit
>> GIT_ERR_UPLOAD_ARCHIVE_EXPECTED_DELIM_PACKET or
Ben Peart writes:
> diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
> index 39133bcbc8..f613dd72e3 100755
> --- a/t/t1700-split-index.sh
> +++ b/t/t1700-split-index.sh
> @@ -7,6 +7,7 @@ test_description='split index mode tests'
> # We need total control of index splitting here
>
Thomas Gummerer writes:
> Thanks, I do think this is a good idea. I do however share Ævar's
> concern in https://public-inbox.org/git/87h8itkz2h@evledraar.gmail.com/.
> I have TEST_GIT_INDEX_VERSION=4 set in my config.mak since quite a
> long time, and had I missed this thread, I would all
Junio C Hamano writes:
> Have you run "make test" with this change?
>
> I expect at least 5505.10 to fail without adjustment.
For now, I'll queue this on top, and if this turns out to be
sufficient, I will squash it in.
t/t5505-remote.sh | 4 ++--
1 file changed,
fatal: No such remote: \n
>
> To make these error messages consistent, quote the name of the remote
> that we tried and failed to find.
>
> Signed-off-by: Shulhan
> Reviewed-by: Junio C Hamano
> ---
> builtin/remote.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 d
Ben Peart writes:
> Rename GIT_FORCE_PRELOAD_TEST to GIT_TEST_PRELOAD for consistency with the
> other GIT_TEST_ special setups and properly document its use.
>
> Signed-off-by: Ben Peart
> ---
>
Among the two unrelated changes that are not mentioned in the
proposed log message, the change to
Derrick Stolee writes:
>> +if (!from_one || from_one->type != OBJ_COMMIT) {
>> +/* no way to tell if this is reachable by
>> + * looking at the ancestry chain alone, so
>> + * leave a note to ourselves not to worry about
>>
Ævar Arnfjörð Bjarmason writes:
> On Wed, Sep 12 2018, Ben Peart wrote:
>
>> -GIT_TEST_OE_DELTA_SIZE= exercises the uncomon pack-objects code
>> +GIT_TEST_OE_DELTA_SIZE= exercises the uncommon pack-objects code
>> path where deltas larger than this limit require extra memory
>> allocation for
Jonathan Tan writes:
>> Instead of explaining why the new convention is better to justify
>> (2), the above three lines handwave by saying "more flexible"
>> twice. We should do better.
>>
>> fetch-object: unify fetch_object[s] functions
>>
>> There are fetch_object() and
Elijah Newren writes:
> This patch cleanly applies to both 2.19.0 and pu. There are some related
> code cleanups that I'd like to make, but doing that cleanup conflicts with
> the various rewrite-rebase-in-C topics sitting in pu; since those are
> fairly lengthy, I really don't want to cause
Ben Peart writes:
> Rename GIT_FSMONITOR_TEST to GIT_TEST_FSMONITOR for consistency with the
> other GIT_TEST_ special setups and properly document its use.
Makes sense.
Thanks for such an attention to detail.
>
> Signed-off-by: Ben Peart
> ---
>
> Notes:
> Base Ref: v2.19.0
>
Junio C Hamano writes:
> "Randall S. Becker" writes:
>
>> The scenario is slightly different.
>> 1. Person A gives me a new binary file-1 with fingerprint A1. This goes into
>> git unchanged.
>> 2. Person B gives me binary file-2 with fingerprint B2. Th
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> We have coverage targets in our Makefile for using gcov to display line
> coverage based on our test suite. The way I like to do it is to run:
>
> make coverage-test
> make coverage-report
>
> This leaves the repo in a
Josh Steadmon writes:
> Signed-off-by: Josh Steadmon
> ---
> builtin/archive.c | 8 +++-
> http-backend.c | 10 +-
> transport-helper.c | 5 +++--
> 3 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/archive.c b/builtin/archive.c
> index
Josh Steadmon writes:
> +static int do_v2_command_and_cap(int out)
> +{
> + packet_write_fmt(out, "command=archive\n");
> + /* Capability list would go here, if we had any. */
> + packet_delim(out);
> +}
> +
> static int run_remote_archiver(int argc, const char **argv,
>
Junio C Hamano writes:
>> -if (packet_read_line(fd[0], NULL))
>> +status = packet_reader_read();
>> +if (status != PACKET_READ_FLUSH)
>> die(_("git archive: expected a flush"));
>
> This makes me wonder what happens if we got an EO
"Randall S. Becker" writes:
> The scenario is slightly different.
> 1. Person A gives me a new binary file-1 with fingerprint A1. This goes into
> git unchanged.
> 2. Person B gives me binary file-2 with fingerprint B2. This does not go
> into git yet.
> 3. We attempt a git diff between the
Derrick Stolee writes:
> On 9/12/2018 6:54 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>>> "Derrick Stolee via GitGitGadget" writes:
>>>
>>>> contrib/coverage-diff.sh | 70
>>&g
Josh Steadmon writes:
> Using packet_reader will simplify version detection and capability
> handling, which will make implementation of protocol v2 support in
> git-archive easier.
Is this meant as a change in implementation without any change in
behaviour?
> Signed-off-by: Josh Steadmon
>
"Randall S. Becker" writes:
>> author is important to our process. My objective is to keep the original file
>> 100% exact as supplied and then ignore any changes to the metadata that I
>> don't care about (like Creator) if the remainder of the file is the same.
That will *not* work. If person
Junio C Hamano writes:
> "Derrick Stolee via GitGitGadget" writes:
>
>> contrib/coverage-diff.sh | 70
>> 1 file changed, 70 insertions(+)
>> create mode 100755 contrib/coverage-diff.sh
>
> I fully appreci
"Derrick Stolee via GitGitGadget" writes:
> contrib/coverage-diff.sh | 70
> 1 file changed, 70 insertions(+)
> create mode 100755 contrib/coverage-diff.sh
I fully appreciate the motivation. But it is a bit sad that this
begins with "#!/bin/bash" but
Jonathan Tan writes:
> fetch-object.h currently provides two functions (fetch_object() and
> fetch_objects()) that could be replaced by a single, more flexible
> function. Replace those two functions with the more flexible function.
The latter half of the first sentence and the second sentence
Shulhan writes:
> Rationale: consistent error format
You can and should drop this line.
> When adding new remote name with empty string, git will print the
> following error message,
>
> fatal: '' is not a valid remote name\n
>
> But when removing remote name with empty string as input, git
"Derrick Stolee via GitGitGadget" writes:
> diff --git a/commit-reach.c b/commit-reach.c
> index 86715c103c..6de72c6e03 100644
> --- a/commit-reach.c
> +++ b/commit-reach.c
> @@ -544,20 +544,31 @@ int can_all_from_reach_with_flag(struct object_array
> *from,
> {
> struct commit **list =
Thomas Gummerer writes:
>> > I'm looking into why that fails. Also adding Dscho to Cc here as the
>> > author of this code.
>>
>> The diff below seems to fix it. Not submitting this as a proper
>> patch [...]
>
> I found the time to actually have a look at the paper, so here's a
> proper
"Derrick Stolee via GitGitGadget" writes:
> There have been a few bugs in recent patches what would have been caught if
> the test suite covered those blocks (including a few of mine). I want to
> work towards a "sensible" amount of coverage on new topics. In my opinion,
> this means that any
William Chargin writes:
> While the `test_dir_is_empty` function appears correct in most normal
> use cases, it can improperly pass if a directory contains a filename
> with a newline, and can improperly fail if an empty directory looks like
> an argument to `ls`. This patch changes the
Stefan Beller writes:
> For Gerrit users that use submodules the invocation of fetch without a
> branch is their main use case.
That's way under explains this commit. It is totally unclear how
that statement of fact relates to the problem this patch is trying
to address; it does not even make
Stefan Beller writes:
> Retry fetching a submodule if the object id that the superproject points
> to, cannot be found.
By object name? By attempting to fetch all refs? Or by doing
something else? Fetching by the exact object name is the most
efficient approach, but the server side may not
Stefan Beller writes:
> This patch started as a refactoring to make 'get_next_submodule' more
> readable, but upon doing so, I realized that git-fetch actually doesn't
> need to be run in the worktree. So let's run it in the git dir instead.
It may be clear to the author but not clear to the
Stefan Beller writes:
> We can string_list_insert() to maintain sorted-ness of the
> list as we find new items, or we can string_list_append() to
> build an unsorted list and sort it at the end just once.
>
> To pick which one is more appropriate, we notice the fact
> that we discover new items
Stefan Beller writes:
> The submodule subsystem is really bad at staying within 80 characters.
> Fix it while we are here.
Makes sense. Thanks.
>
> Signed-off-by: Stefan Beller
> ---
> submodule.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/submodule.c
Stefan Beller writes:
> Helped-by: Junio C Hamano
> Signed-off-by: Stefan Beller
> ---
> sha1-array.c | 18 ++
> sha1-array.h | 5 +
> 2 files changed, 23 insertions(+)
>
> diff --git a/sha1-array.c b/sha1-array.c
> index 265941fbf40..7632
Stefan Beller writes:
> Add a few functions to allow a string-list to be used as a stack:
>
> - string_list_last() lets a caller peek the string_list_item at the
>end of the string list. The caller needs to be aware that it is
>borrowing a pointer, which can become invalid if/when the
Shulhan writes:
> Rationale: consistent error format
>
> When adding new remote name with empty string, git will print the
> following error message,
>
> fatal: '' is not a valid remote name\n
>
> But when removing remote name with empty string as input, git did not
> print the empty string
Jeff King writes:
> I really wonder if this topic is worth pursuing further without finding
> a real-world case that actually fails with the v2.19 code. I.e., is
> there actually a server that doesn't set CONTENT_LENGTH and really can't
> handle read-to-eof? It's plausible to me, but it's also
Stephen & Linda Smith writes:
> On Tuesday, September 11, 2018 3:20:19 PM MST Junio C Hamano wrote:
>>
>> * jc/wt-status-state-cleanup (2018-09-07) 1 commit
>> - WIP: roll wt_status_state into wt_status and populate in the collect
>> phase (this branc
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
Git 2.19 is out. The tip of
Junio C Hamano writes:
>> +test_expect_success 'format-patch --range-diff as commentary' '
>> +git format-patch --stdout --range-diff=HEAD~1 HEAD~1 >actual &&
>> +grep -A 1 -e "\-\-\-" actual | grep "Range-diff:"
>
> Isn't &q
"Derrick Stolee via GitGitGadget" writes:
> From: Derrick Stolee
>
> The commit 40ce4160 "format-patch: allow --range-diff to apply to
> a lone-patch" added the ability to see a range-diff as commentary
> after the commit message of a single patch series (i.e. [PATCH]
> instead of [PATCH X/N]).
Stefan Beller writes:
>> >>
>> >> [1]
>> >> https://public-inbox.org/git/1421343725-3973-1-git-send-email-kuleshovm...@gmail.com/
>> >> Signed-off-by: Stefan Beller
>> >
>> > I'll add a blank line before the sign-off. Is this an example that
>> > our "where is the existing trailer?" code
Elijah Newren writes:
> check_one_conflict() compares `i` to `active_nr` in two places to avoid
> buffer overruns, but left out an important third location.
>
> The code did used to have a check here comparing i to active_nr, back
> before commit fb70a06da2f1 ("rerere: fix an off-by-one
Jeff King writes:
> I think that's syntactically invalid. At any rate, there are clearly
> three options for setting a bit:
>
> 1. In the section header (+include, or Ævar's includeIf suggestion).
>
> 2. In another key (which looks pretty clean, but does introduce
> ordering
Ævar Arnfjörð Bjarmason writes:
> Based on feedback on v1, and the "this is yelling at my users through
> gc.log" bug I found.
I notice that between 'master' and 'pu' there already is one new
callsite of the write_commit_graph_reachable() function; because I
suspect that we will discover more
Johannes Sixt writes:
>>> Like this (generated using "git revert -m1)?
>>
>> OK. Thanks for taking care of it.
>
> Please don't forget to remove the corresponding release notes entry.
Thanks for a reminder. Very much appreciated.
901 - 1000 of 27729 matches
Mail list logo
