Re: [PATCH] completion: optionally disable checkout DWIM

Jeff King writes: > ... But I think it's really the > completion that bugs me. The DWIM is easy to avoid triggering if you > just don't feed it the remote branch names. It's the completion that > routinely leads me to doing that. :) True.

Re: [PATCH] completion: optionally disable checkout DWIM

On Thu, Apr 20, 2017 at 10:01:32PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > When we complete branch names for "git checkout", we also > > complete remote branch names that could trigger the DWIM > > behavior. Depending on your workflow and project, this can > > be

Re: [PATCH] completion: optionally disable checkout DWIM

Jeff King writes: > When we complete branch names for "git checkout", we also > complete remote branch names that could trigger the DWIM > behavior. Depending on your workflow and project, this can > be either convenient or annoying. > ... > This is flexible enough for me, but

Re: [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

I think I meant to write "big pidfiles" there. With xsize_t() gc would die when seeing a pidfile whose size doesn't fit into size_t. The version I sent just ignores such files. However, it would choke on slightly smaller files that happen to not fit into memory. And no reasonable pidfile

Re: [PATCH 0/6] removing more calls to git_path()

All patches in the series looked sensible. Thanks.

Re: [BUG] test suite broken with GIT_TEST_SPLIT_INDEX

Christian Couder writes: > Could you try with the following patch: > > http://public-inbox.org/git/20170330210354.20018-1-chrisc...@tuxfamily.org/ Ah, this reminds me. The patch has been in the stalled state for quite some time due to confusing description. How

Re: [PATCH 00/15] Handle fopen() errors

Junio C Hamano writes: > I wonder if it is OK to only special case ENOENT for !fp cases, > where existing code silently returns. Perhaps it is trying to read > an optional file, and it returns silently because lack of it is > perfectly OK for the purpose of the code. Are

Re: [PATCH 6/6] worktree remove: new command

Nguyễn Thái Ngọc Duy writes: > + worktrees = get_worktrees(0); > + wt = find_worktree(worktrees, prefix, av[0]); > + if (!wt) > + die(_("'%s' is not a working directory"), av[0]); > + if (is_main_worktree(wt)) > + die(_("'%s' is a main

Re: [PATCH 5/6] worktree move: refuse to move worktrees with submodules

Nguyễn Thái Ngọc Duy writes: > Submodules contains .git files with relative paths. After a worktree > move, these files need to be updated or they may point to nowhere. > > This is a bandage patch to make sure "worktree move" don't break > people's worktrees by accident. When

Re: [PATCH 4/6] worktree move: accept destination as directory

Nguyễn Thái Ngọc Duy writes: > Similar to "mv a b/", which is actually "mv a b/a", we extract basename > of source worktree and create a directory of the same name at > destination if dst path is a directory. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- >

Re: [PATCH 3/6] worktree move: new command

Nguyễn Thái Ngọc Duy writes: > There are two options to move the main worktree, but both have > complications, so it's not implemented yet. Anyway the options are: > > - convert the main worktree to a linked one and move it away, leave the >git repository where it is.

Re: [PATCH 2/6] worktree.c: add update_worktree_location()

Nguyễn Thái Ngọc Duy writes: > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > worktree.c | 21 + > worktree.h | 6 ++ > 2 files changed, 27 insertions(+) > > diff --git a/worktree.c b/worktree.c > index 40cc031ac9..c695dcf982 100644

Re: [PATCH 1/6] worktree.c: add validate_worktree()

Nguyễn Thái Ngọc Duy writes: > This function is later used by "worktree move" and "worktree remove" > to ensure that we have a good connection between the repository and > the worktree. For example, if a worktree is moved manually, the > worktree location recorded in

Re: [PATCH 00/15] Handle fopen() errors

Nguyễn Thái Ngọc Duy writes: > Some of you may recall a while back, nd/conditional-config-include > failed on Windows because I accidentally fopen()'d a directory in a > test, but it's not considered an serious error unless it's on Windows, > where fopen() returns NULL. > > A

Re: [PATCH v1] diffcore-rename: speed up register_rename_src

Jeff King writes: > - this patch probably adds "unsorted tree" to the list of breakages > that would cause us to skip rename detection. I don't know if that's > actually possible in practice (i.e., do we end up sorting the > diffq elsewhere anyway?). I also wondered

Re: [PATCH] refs.h: rename submodule arguments to submodule_path

Stefan Beller writes: > + Junio Just like Michael, I do not have strong enough opinion for or against this patch to comment on it. I do agree with you that it would be a good longer-term direction to use "submodule" for a "struct submodule" (i.e. submodule object), and call

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Brandon Williams writes: > On 04/20, Brandon Williams wrote: >> On 04/20, Johannes Schindelin wrote: >> > Hi Lars & Junio, >> > >> > On Thu, 20 Apr 2017, Lars Schneider wrote: >> > >> > > > * bw/forking-and-threading (2017-04-19) 11 commits >> > > > - run-command: block

Re: [PATCH] test-lib: abort when can't remove trash directory

SZEDER Gábor writes: > We had two similar bugs in the tests sporadically triggering error > messages during the removal of the trash directory, see commits > bb05510e5 (t5510: run auto-gc in the foreground, 2016-05-01) and > ef09036cf (t6500: wait for detached auto gc at

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

On 04/20, Brandon Williams wrote: > On 04/20, Johannes Schindelin wrote: > > Hi Lars & Junio, > > > > On Thu, 20 Apr 2017, Lars Schneider wrote: > > > > > > * bw/forking-and-threading (2017-04-19) 11 commits > > > > - run-command: block signals between fork and execve > > > > - run-command: add

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Lars Schneider writes: >> * bw/forking-and-threading (2017-04-19) 11 commits >> - run-command: block signals between fork and execve >> - run-command: add note about forking and threading >> - run-command: handle dup2 and close errors in child >> - run-command:

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Lars Schneider writes: > Sorry for sending this email multiple times. My mobile email client created > html... Should be fixed now! > >> >> * ls/filter-process-delayed (2017-03-06) 1 commit >> - convert: add "status=delayed" to filter process protocol >> >> What's

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Jeff King writes: >> if (!ret && opts->keep_locked) >> -; >> +; /* --lock wants to keep "locked" file */ >> else >> unlink_or_warn(sb.buf); > > I know this is just a drive-by comment, but given that the "else" is the >

Re: What's cooking in git.git (Apr 2017, #04; Wed, 19)

Duy Nguyen writes: > Looking good. I would add some comment, lest ';' feel lonely. But it's > really personal taste. ... which matches mine. Thanks for the update (which I'll squash in). > > -- 8< -- > diff --git a/builtin/worktree.c b/builtin/worktree.c > index

Re: [PATCH 2/2] clone: remember references for submodules even when not recursing

On Thu, Apr 20, 2017 at 3:12 PM, Brandon Williams wrote: > On 04/11, Stefan Beller wrote: >> The commit 31224cbdc7 (clone: recursive and reference option triggers >> submodule alternates, 2016-08-17) argued for any further `submodule update` >> to respect the initial setup.

Re: [PATCH v3 03/18] grep: submodule-related case statements should die if new fields are added

On Thu, Apr 20, 2017 at 03:20:16PM -0700, Brandon Williams wrote: > On 04/20, Ævar Arnfjörð Bjarmason wrote: > > Change two case statements added in commit 0281e487fd ("grep: > > optionally recurse into submodules", 2016-12-16) so that they die if > > new GREP_PATTERN_* enum fields are added

Re: [PATCH 1/2] submodule.c: add has_submodules to check if we have any submodules

On 04/20, Stefan Beller wrote: > On Thu, Apr 20, 2017 at 3:07 PM, Brandon Williams wrote: > > On 04/11, Stefan Beller wrote: > >> +int has_submodules(unsigned what_to_check) > >> +{ > >> + if (what_to_check & SUBMODULE_CHECK_ANY_CONFIG) { > >> + if

Re: [PATCH v3 01/18] grep: amend submodule recursion test in preparation for rx engine testing

On 04/20, Ævar Arnfjörð Bjarmason wrote: > Amend the submodule recursion test added in commit 0281e487fd ("grep: > optionally recurse into submodules", 2016-12-16) to prepare it for > subsequent tests of whether it passes along the grep.patternType to > the submodule greps. > > This is just the

Re: [PATCH 1/2] submodule.c: add has_submodules to check if we have any submodules

On Thu, Apr 20, 2017 at 3:07 PM, Brandon Williams wrote: > On 04/11, Stefan Beller wrote: >> +int has_submodules(unsigned what_to_check) >> +{ >> + if (what_to_check & SUBMODULE_CHECK_ANY_CONFIG) { >> + if (submodule_config_reading == SUBMODULE_CONFIG_NOT_READ)

Re: [PATCH v3 03/18] grep: submodule-related case statements should die if new fields are added

On 04/20, Ævar Arnfjörð Bjarmason wrote: > Change two case statements added in commit 0281e487fd ("grep: > optionally recurse into submodules", 2016-12-16) so that they die if > new GREP_PATTERN_* enum fields are added without updating them. > > These case statements currently check for an

Re: [PATCH 2/2] clone: remember references for submodules even when not recursing

On 04/11, Stefan Beller wrote: > The commit 31224cbdc7 (clone: recursive and reference option triggers > submodule alternates, 2016-08-17) argued for any further `submodule update` > to respect the initial setup. This is not the case if you only pass > '--reference[-if-able]' to the initial clone

Re: [PATCH 1/2] submodule.c: add has_submodules to check if we have any submodules

On 04/11, Stefan Beller wrote: > +int has_submodules(unsigned what_to_check) > +{ > + if (what_to_check & SUBMODULE_CHECK_ANY_CONFIG) { > + if (submodule_config_reading == SUBMODULE_CONFIG_NOT_READ) > + load_submodule_config(); > + if

RE: [PATCH] Increase core.packedGitLimit

> -Original Message- > From: Johannes Schindelin [mailto:johannes.schinde...@gmx.de] > Sent: Thursday, April 20, 2017 5:58 PM > To: Jeff King > Cc: David Turner ; git@vger.kernel.org > Subject: Re: [PATCH] Increase core.packedGitLimit > > Hi

Re: [PATCH] Increase core.packedGitLimit

Hi Peff, On Thu, 20 Apr 2017, Jeff King wrote: > On Thu, Apr 20, 2017 at 04:41:18PM -0400, David Turner wrote: > > > When core.packedGitLimit is exceeded, git will close packs. If there > > is a repack operation going on in parallel with a fetch, the fetch > > might open a pack, and then be

[BUG] test suite broken with GETTEXT_POISON=YesPlease

As a refresh of everyone's memory (because mine needed it). This is a feature I added back in 2011 when the i18n support was initially added. There was concern at the time that we would inadvertently mark plumbing messages for translation, particularly something in a shared code path, and this

Re: Linus' sha1 is much faster!

A Phádraig, cá bhfuil tú i do chónaí? Tá mé i gCalafoirne. -- View this message in context: http://git.661346.n2.nabble.com/Linus-sha1-is-much-faster-tp3448007p7657474.html Sent from the git mailing list archive at Nabble.com.

Re: Linus' sha1 is much faster!

I also wanted to include Linus' sha1 in our software at work. But the GPLv2 license was incompatible. Too bad it is just just in the public domain. I grabbed Steve Reid's public domain code from 1999 and ran it. It produced the same output. I ran it on a 3GB input file, and Linus' code from 2009

[PATCH v3 17/18] grep: remove support concurrent use of both PCRE v1 & v2

Remove the support for concurrently using PCRE v1 & v2 by compiling Git with support for both. Having access to both at runtime via grep.patternType=[pcre1|pcre2] makes it easier for the developer hacking on the PCRE implementations to test them concurrently, but adds confusion for everyone else,

[PATCH v3 15/18] grep: add support for the PCRE v1 JIT API

Change the grep PCRE v1 code to use JIT when available. When PCRE support was initially added in commit 63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09) PCRE had no JIT support, it was integrated into 8.20 released on 2011-10-21. When JIT support is enabled the PCRE performance usually improves by

[PATCH v3 16/18] grep: add support for PCRE v2

Add support for v2 of the PCRE API. This is a new major version of PCRE that came out in early 2015[1]. The regular expression syntax is the same, but while the API is similar-ish, pretty much every function is either renamed or takes different arguments. Thus using it via entirely new functions

[PATCH v3 18/18] Makefile & configure: make PCRE v2 the default PCRE implementation

Change the USE_LIBPCRE=YesPlease & --with-libpcre flags to the Makefile & configure script, respectively, to mean use PCRE v2, not PCRE v1. The legacy library is still available on request via USE_LIBPCRE1=YesPlease or --with-libpcre1. Signed-off-by: Ævar Arnfjörð Bjarmason ---

[PATCH v3 10/18] grep: make grep.patternType=[pcre|pcre1] a synonym for "perl"

Make the pattern types "pcre" & "pcre1" synonyms for the long-standing "perl" grep.patternType. This change is part of a longer patch series to add pcre2 support to Git. It's nice to be able to performance test PCRE v1 v.s. v2 without having to recompile git, and doing that via grep.patternType

[PATCH v3 12/18] grep: change the internal PCRE macro names to be PCRE1

Change the internal USE_LIBPCRE define, & build options flag to use a naming convention ending in PCRE1, without changing the long-standing USE_LIBPCRE Makefile flag which enables this code. This is for preparation for libpcre2 support where having things like USE_LIBPCRE and USE_LIBPCRE2 in any

[PATCH v3 13/18] grep: change the internal PCRE code & header names to be PCRE1

Change the internal PCRE variable & function names to have a "1" suffix. This is for preparation for libpcre2 support, where having non-versioned names would be confusing. The earlier "grep: change the internal PCRE macro names to be PCRE1" change elaborates on the motivations behind this commit.

[PATCH v3 14/18] perf: add a performance comparison test of grep -E and -P

Add a very basic performance comparison test comparing the POSIX extended & pcre1 engines. I'm skipping the "basic" POSIX engine because supporting its alternate regex syntax is hard, although it would be interesting to test it, at least under glibc it seems to be an entirely different engine,

[PATCH v3 11/18] test-lib: rename the LIBPCRE prerequisite to PCRE

Rename the LIBPCRE prerequisite to PCRE. This is for preparation for libpcre2 support, where having just "LIBPCRE" would be confusing as it implies v1 of the library. None of these tests are incompatible between versions 1 & 2 of libpcre, it's less confusing to give them a more general name to

[PATCH v3 07/18] log: add exhaustive tests for pattern style options & config

Add exhaustive tests for how the different grep.patternType options & the corresponding command-line options affect git-log. Before this change it was possible to patch revision.c so that the --basic-regexp option was synonymous with --extended-regexp, and --perl-regexp wasn't recognized at all,

[PATCH v3 06/18] grep: add a test for backreferences in PCRE patterns

Add a test for backreferences such as (.)\1 in PCRE patterns. This test ensures that the PCRE_NO_AUTO_CAPTURE option isn't turned on. Before this change turning it on would break these sort of patterns, but wouldn't break any tests. Signed-off-by: Ævar Arnfjörð Bjarmason ---

Re: [BUG] test suite broken with GIT_TEST_SPLIT_INDEX

On 04/20, Christian Couder wrote: > Hi, > > On Thu, Apr 20, 2017 at 10:52 PM, Thomas Gummerer > wrote: > > Hi, > > > > I just tried to run the test suite with GIT_TEST_SPLIT_INDEX=YesPlease > > and noticed that a few tests are broken both in pu and master. > > > > Below

[PATCH v3 09/18] grep & rev-list doc: stop promising libpcre for --perl-regexp

Stop promising in our grep & rev-list options documentation that we're always going to be using libpcre when given the --perl-regexp option. Instead talk about using "Perl-compatible regular expressions" and using these types of patterns using "a compile-time dependency". Saying "libpcre"

[PATCH v3 08/18] log: add -P as a synonym for --perl-regexp

Add a short -P option as a synonym for the longer --perl-regexp, for consistency with the options the corresponding grep invocations accept. This was intentionally omitted in commit 727b6fc3ed ("log --grep: accept --basic-regexp and --perl-regexp", 2012-10-03) for unspecified future use. Since

[PATCH v3 04/18] grep: remove redundant regflags assignment under PCRE

Remove a redundant assignment to the "regflags" variable. This variable is only used for POSIX regular expression matching, not when the PCRE library is used. This redundant assignment was added as a result of copy/paste programming in commit 84befcd0a4 ("grep: add a grep.patternType

[PATCH v3 05/18] Makefile & configure: reword outdated comment about PCRE

Reword an outdated comment which suggests that only git-grep can use PCRE. This comment was added back when PCRE support was initially added in commit 63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09), and was true at the time. It hasn't been telling the full truth since git-log learned to use

[PATCH v3 02/18] grep: add tests for grep pattern types being passed to submodules

Add testing for grep pattern types being correctly passed to submodules. The pattern "(.|.)[\d]" matches differently under fixed (not at all), and then matches different lines under basic/extended & perl regular expressions, so this change asserts that the pattern type is passed along correctly.

[PATCH v3 03/18] grep: submodule-related case statements should die if new fields are added

Change two case statements added in commit 0281e487fd ("grep: optionally recurse into submodules", 2016-12-16) so that they die if new GREP_PATTERN_* enum fields are added without updating them. These case statements currently check for an exhaustive list of fields, but if a new field is added

[PATCH v3 01/18] grep: amend submodule recursion test in preparation for rx engine testing

Amend the submodule recursion test added in commit 0281e487fd ("grep: optionally recurse into submodules", 2016-12-16) to prepare it for subsequent tests of whether it passes along the grep.patternType to the submodule greps. This is just the result of searching & replacing: foobar ->

[PATCH v3 00/18] PCRE v1 improvements & PCRE v2 support

Sorry about the high volume sending. I thought I wouldn't have time to work on v3 for a while, but here it is a day later. I promise to hold off on further sending for a bit. This, unlike v2, addresses all the outstanding comments the series had. Most importantly I added a patch at the end to

[PATCH 5/6] replace strbuf_addstr(git_path()) with git_path_buf()

Writing directly into the strbuf avoids a useless copy of the data, and dropping calls to git_path() makes it easier to audit for dangerous calls. Note that git_path() does an implicit strbuf_reset(), but in each of these cases we were either already doing that reset, or writing into a fresh

[PATCH 6/6] am: drop "dir" parameter from am_state_init

The only caller of this function passes in a static buffer returned from git_path(). This looks dangerous at first glance, but turns out to be OK because the first thing we do is xstrdup() the result. Let's turn this into a git_pathdup(). That's slightly more efficient (no extra copy), and makes

[PATCH 4/6] replace xstrdup(git_path(...)) with git_pathdup(...)

It's more efficient to use git_pathdup(), as it skips an extra copy of the path. And by removing some calls to git_path(), it makes it easier to audit for dangerous uses. Signed-off-by: Jeff King --- builtin/config.c | 5 +++-- fast-import.c| 2 +- 2 files changed, 4

[PATCH 3/6] use git_path_* helper functions

Long ago we added functions like git_path_merge_msg() to replace the more dangerous git_path("MERGE_MSG"). Over time some new calls to the latter have crept it. Let's convert them to use the safer form. Signed-off-by: Jeff King --- builtin/commit.c | 6 +++--- builtin/pull.c |

[PATCH 1/6] bisect: add git_path_bisect_terms helper

This avoids using the dangerous git_path(). Right now there's only one call site (because the writing half is still part of the shell script), but it may come in handy in the future as more of bisect is written in C. It also matches how we access the other BISECT_* files. Signed-off-by: Jeff King

[PATCH 2/6] branch: add edit_description() helper

Rather than have a variable with a short name that is fed to git_path(), let's add a helper function that returns the full path. This avoids the dangerous git_path() function. Signed-off-by: Jeff King --- builtin/branch.c | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH 0/6] removing more calls to git_path()

After the discussion about the git_path()-related bug in: http://public-inbox.org/git/20170329080820.8084-1-chrisc...@tuxfamily.org/ I looked over some of the calls. When I introduced git_pathdup() a few years ago I converted most of the dangerous git_path() calls. But there were still some

Re: [BUG] test suite broken with GIT_TEST_SPLIT_INDEX

On Thu, Apr 20, 2017 at 09:52:14PM +0100, Thomas Gummerer wrote: > I just tried to run the test suite with GIT_TEST_SPLIT_INDEX=YesPlease > and noticed that a few tests are broken both in pu and master. > [...] > Bisecting between master and v2.10.0 leads me to the merge commit > 94c9b5af70

Re: [BUG] test suite broken with GIT_TEST_SPLIT_INDEX

Hi, On Thu, Apr 20, 2017 at 10:52 PM, Thomas Gummerer wrote: > Hi, > > I just tried to run the test suite with GIT_TEST_SPLIT_INDEX=YesPlease > and noticed that a few tests are broken both in pu and master. > > Below the test failures on master: > > Test Summary Report >

Re: [PATCH] Increase core.packedGitLimit

On Thu, Apr 20, 2017 at 04:41:18PM -0400, David Turner wrote: > When core.packedGitLimit is exceeded, git will close packs. If there > is a repack operation going on in parallel with a fetch, the fetch > might open a pack, and then be forced to close it due to > packedGitLimit being hit. The

[PATCH v3 6/8] Introduce a new data type for timestamps

Git's source code assumes that unsigned long is at least as precise as time_t. Which is incorrect, and causes a lot of problems, in particular where unsigned long is only 32-bit (notably on Windows, even in 64-bit versions). So let's just use a more appropriate data type instead. In preparation

[PATCH v3 7/8] Abort if the system time cannot handle one of our timestamps

We are about to switch to a new data type for time stamps that is definitely not smaller or equal, but larger or equal to time_t. So before using the system functions to process or format timestamps, let's make extra certain that they can handle what we feed them. Signed-off-by: Johannes

[PATCH v3 5/8] Introduce a new "printf format" for timestamps

Currently, Git's source code treats all timestamps as if they were unsigned longs. Therefore, it is okay to write "%lu" when printing them. There is a substantial problem with that, though: at least on Windows, time_t is *larger* than unsigned long, and hence we will want to switch away from the

[PATCH v3 8/8] Use uintmax_t for timestamps

Previously, we used `unsigned long` for timestamps. This was only a good choice on Linux, where we know implicitly that `unsigned long` is what is used for `time_t`. However, we want to use a different data type for timestamps for two reasons: - there is nothing that says that `unsigned long`

[PATCH v3 3/8] t0006 & t5000: skip "far in the future" test when time_t is too limited

Git's source code refers to timestamps as unsigned long, which is ill-defined, as there is no guarantee about the number of bits that data type has. In preparation of switching to another data type that is large enough to hold "far in the future" dates, we need to prepare the t0006-date.sh script

[PATCH v3 4/8] Specify explicitly where we parse timestamps

Currently, Git's source code represents all timestamps as `unsigned long`. In preparation for using a more appropriate data type, let's introduce a symbol `parse_timestamp` (currently being defined to `strtoul`) where appropriate, so that we can later easily switch to, say, use `strtoull()`

[PATCH v3 2/8] t0006 & t5000: prepare for 64-bit timestamps

Git's source code refers to timestamps as unsigned longs. On 32-bit platforms, as well as on Windows, unsigned long is not large enough to capture dates that are "absurdly far in the future". It is perfectly valid by the C standard, of course, for the `long` data type to refer to 32-bit integers.

[PATCH v3 0/8] Introduce timestamp_t for timestamps

Git v2.9.2 was released in a hurry to accomodate for platforms like Windows, where the `unsigned long` data type is 32-bit even for 64-bit setups. The quick fix was to simply disable all the testing with "absurd" future dates. However, we can do much better than that, as we already make use of

[PATCH v3 1/8] ref-filter: avoid using `unsigned long` for catch-all data type

In its `atom_value` struct, the ref-filter source code wants to store different values in a field called `ul` (for `unsigned long`), e.g. timestamps. However, as we are about to switch the data type of timestamps away from `unsigned long` (because it may be 32-bit even when `time_t` is 64-bit),

[BUG] test suite broken with GIT_TEST_SPLIT_INDEX

Hi, I just tried to run the test suite with GIT_TEST_SPLIT_INDEX=YesPlease and noticed that a few tests are broken both in pu and master. Below the test failures on master: Test Summary Report --- t7009-filter-branch-null-sha1.sh (Wstat: 256 Tests: 5 Failed: 2)

Re: [PATCH v5 02/11] t0061: run_command executes scripts without a #! line

On 04/20, Johannes Schindelin wrote: > Hi Brandon, > > On Thu, 20 Apr 2017, Brandon Williams wrote: > > > On 04/20, Johannes Schindelin wrote: > > > > > > On Wed, 19 Apr 2017, Brandon Williams wrote: > > > > > > > On 04/19, Johannes Sixt wrote: > > > > > Am 19.04.2017 um 07:43 schrieb Johannes

[PATCH] Increase core.packedGitLimit

When core.packedGitLimit is exceeded, git will close packs. If there is a repack operation going on in parallel with a fetch, the fetch might open a pack, and then be forced to close it due to packedGitLimit being hit. The repack could then delete the pack out from under the fetch, causing the

[PATCH 6/6] docs/bisect-lk2009: update java code conventions link

The old link just redirects to a big index page. I was able to find a new link for the original document via Google. Signed-off-by: Jeff King --- Documentation/git-bisect-lk2009.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH 5/6] docs/bisect-lk2009: update nist report link

The original NIST press release linked here is no longer available. But it was just a one-page summary of a larger planning report; we can link to the report and point people to the executive summary, which contains the same information. Ideally we'd cite it with a DOI, but I couldn't dig one up

[PATCH 4/6] docs/archimport: quote sourcecontrol.net reference

git-archimport has an option to register archives at mirrors.sourcecontrol.net. The sourcecontrol.net domain still exists, but that hostname no longer exists. That means this feature is presumably broken. I'll leave the examination and modification of that to people who might actually use

[PATCH 3/6] gitcore-tutorial: update broken link

The slides for the Linux-mentoring presentation are no longer available. Let's point to the wayback version of the page, which works. Note that the referenced diagram is also available on page 15 of [1]. We could link to that instead, but it's not clear from the URL scheme ("uploads") whether

[PATCH 1/6] doc: use https links to avoid http redirect

Many sites these days unconditionally redirect http requests to their https equivalents. Let's make our links https in the first place to save the client a redirect. Signed-off-by: Jeff King --- Documentation/git-bisect-lk2009.txt | 10 +-

[PATCH 2/6] doc: replace or.cz gitwiki link with git.wiki.kernel.org

The or.cz version of the Git wiki went away long ago, and now just redirects to kernel.org. Signed-off-by: Jeff King --- Documentation/git-tools.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt index

[PATCH 0/6] fix broken links in Documentation/

I've been looking at running an automated link-checker on git-scm.com. But as it hosts HTML rendered from our Documentation/ directory, it inherits any broken links that we have here. :) This series fixes all the issues I could find. [1/6]: doc: use https links to avoid http redirect [2/6]:

Re: [PATCH v5 02/11] t0061: run_command executes scripts without a #! line

Hi Brandon, On Thu, 20 Apr 2017, Brandon Williams wrote: > On 04/20, Johannes Schindelin wrote: > > > > On Wed, 19 Apr 2017, Brandon Williams wrote: > > > > > On 04/19, Johannes Sixt wrote: > > > > Am 19.04.2017 um 07:43 schrieb Johannes Sixt: > > > > >Am 19.04.2017 um 01:17 schrieb Brandon

[PATCH] connect.c: fix leak in handle_ssh_variant

When we see an error from split_cmdline(), we exit the function without freeing the copy of the command string we made. This was sort-of introduced by 22e5ae5c8 (connect.c: handle errors from split_cmdline, 2017-04-10). The leak existed before that, but before that commit fixed the bug, we could

Re: [PATCH] repack: respect gc.pid lock

On Thu, Apr 20, 2017 at 08:10:24PM +, David Turner wrote: > > Is "-a" or "-A" the key factor? Are there current callers who prefer the > > current > > behavior of "possibly duplicate some work, but never report failure" versus > > "do > > not duplicate work, but sometimes fail due to lock

[PATCH] completion: optionally disable checkout DWIM

When we complete branch names for "git checkout", we also complete remote branch names that could trigger the DWIM behavior. Depending on your workflow and project, this can be either convenient or annoying. For instance, my clone of gitster.git contains 74 local "jk/*" branches, but origin

RE: [PATCH] repack: respect gc.pid lock

> -Original Message- > From: Jeff King [mailto:p...@peff.net] > Sent: Tuesday, April 18, 2017 1:50 PM > To: David Turner > Cc: git@vger.kernel.org; christian.cou...@gmail.com; mf...@codeaurora.org; > jacob.kel...@gmail.com > Subject: Re: [PATCH] repack: respect

Re: [PATCHv2 0/4] recursive submodules: git-reset!

On Thu, Apr 20, 2017 at 12:41 PM, Brandon Williams wrote: > On 04/18, Stefan Beller wrote: >> v2: >> * improved commit message to be proper English (Thanks, Philip!) >> * clarified why the patch 2 is so short (i.e. it doesn't matter if the >> submodule >> is initialized in

Re: [PATCHv2 0/4] recursive submodules: git-reset!

On 04/18, Stefan Beller wrote: > v2: > * improved commit message to be proper English (Thanks, Philip!) > * clarified why the patch 2 is so short (i.e. it doesn't matter if the > submodule > is initialized in the preparation repo, we care about the actual testing > repo! > Thanks, Brandon)

Re: [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

Am 20.04.2017 um 20:37 schrieb Torsten Bögershausen: On 2017-04-19 22:02, René Scharfe wrote: Am 19.04.2017 um 21:09 schrieb Torsten Bögershausen: On 2017-04-19 19:28, René Scharfe wrote: [] One or two minor comments inline diff --git a/builtin/gc.c b/builtin/gc.c index 2daede7820..4c1c01e87d

Re: [PATCH] test-lib: abort when can't remove trash directory

On Thu, Apr 20, 2017 at 06:52:30PM +0200, SZEDER Gábor wrote: > We had two similar bugs in the tests sporadically triggering error > messages during the removal of the trash directory, see commits > bb05510e5 (t5510: run auto-gc in the foreground, 2016-05-01) and > ef09036cf (t6500: wait for

Re: [PATCH v3 1/2] use HOST_NAME_MAX to size buffers for gethostname(2)

On 2017-04-19 22:02, René Scharfe wrote: > Am 19.04.2017 um 21:09 schrieb Torsten Bögershausen: >> On 2017-04-19 19:28, René Scharfe wrote: >> [] >> One or two minor comments inline >>> diff --git a/builtin/gc.c b/builtin/gc.c >>> index 2daede7820..4c1c01e87d 100644 >>> --- a/builtin/gc.c >>> +++

Re: [PATCH v1] diffcore-rename: speed up register_rename_src

On Thu, Apr 20, 2017 at 02:08:46PM -0400, Jeff Hostetler wrote: > > That's not the minimal change you were going for, but I think the end > > result is simpler and more consistent. > > OK, let me take a stab at something like that and > see where it takes me. Thanks. I set the patch as a lump,

Re: [PATCH] refs.h: rename submodule arguments to submodule_path

+ Junio On Wed, Apr 12, 2017 at 1:00 PM, Stefan Beller wrote: > In submodule land we carefully need to distinguish between the path of a > submodule and its name. > > The path of a submodule is the path that is recorded in the working tree > of the superproject and describes

Re: [PATCH v1] diffcore-rename: speed up register_rename_src

On 4/20/2017 12:13 PM, Jeff King wrote: On Thu, Apr 20, 2017 at 10:00:04AM -0400, Jeff Hostetler wrote: Perhaps the thing to learn from this (and the other ones) is that we have lots of places where we are building a sorted list by iterating over a sorted list. The insert routines are

Re: [PATCH] git-p4: improve branch option handling

On 20 April 2017 at 14:52, Andrew Oakley wrote: > It is sometimes useful (much quicker) to request commands only operate > on a single branch. > > The P4Sync command has been updated to handle self.branch being None for > consitency with the P4Submit. Should that be

Re: [PATCH v5 3/8] convert: Split start_multi_file_filter into two separate functions

On 4/11/2017 4:05 PM, Jeff King wrote: On Tue, Apr 11, 2017 at 10:01:02PM +0200, Lars Schneider wrote: If you initialize errno to 0 right before a syscall, then yes, you can trust it without checking the return value of the syscall. I wouldn't trust it before calling more complicated

  1   2   >