On 04/21/2017 08:32 AM, Michael Haggerty wrote:
> [...]
> I've CCed Duy because I don't know whether he has more plans regarding
> submodule references [...] get rid of the
> `for_each_ref_submodule()` family of functions entirely.
>
> So perhaps the code that this patch touches won't be around lo
On 04/21/2017 03:12 AM, Junio C Hamano wrote:
> 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 su
On Thu, Apr 20, 2017 at 06:25:59PM +0700, Nguyễn Thái Ngọc Duy wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> builtin/log.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/log.c b/builtin/log.c
> index b3b10cc1ed..26d6a3cf14 100644
> --- a/builtin/log.c
On Thu, Apr 20, 2017 at 08:41:32PM -0700, Junio C Hamano wrote:
> 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
Johannes Schindelin writes:
> Note: while the `time_t` data type exists and is meant to be used for
> timestamps, on 32-bit Linux it is *still* 32-bit. An earlier iteration
> used `time_t` for that reason, but it came with a few serious downsides:
> as `time_t` can be signed (and indeed, on Windo
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.
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 either convenient
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 it's possible someb
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 can
All patches in the series looked sensible. Thanks.
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 about explaining
it like so and
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 there cases where
> thi
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 working directory"),
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 .git file update co
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
> ---
> builtin/worktree.c | 19 +
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. The repo essentially b
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
> --- a/worktree.c
> +++ b/worktree.c
>
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 $GIT_DIR/worktrees/.../gitdi
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 couple of suggestio
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 if it might run
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 a string that names
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 signals between fork and
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 the end of the test
> scr
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 n
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: eliminate calls to error handling f
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 the status of this one???
>>
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
> only thing that doe
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 5ebdcce793..bc75676bf3 100644
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. This is not the case if
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 witho
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 (submodule_config_reading == SUBM
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
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)
>> +
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 exhaust
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 w
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 (submodule_confi
> -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 Peff,
>
> On Thu, 20 Apr 2017, Jeff King wrot
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 for
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 was
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.
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 ta
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,
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
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 m
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
---
Makefile | 21
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 m
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.
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 ma
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, sin
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 mak
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, a
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
---
t/t7810-grep.sh | 7
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 the test failures on mast
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" strongl
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 no
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
configuration
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
PCRE
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.
S
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 it'
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 -> (1|2)d(
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 remo
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 strbu
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 i
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 insertions(+), 3 deletio
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 | 4 ++--
sequen
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
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 deletions(-)
diff --git a/
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 lef
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 ("Merg
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
> ---
> t70
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 rep
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
fo
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 Schindel
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 i
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` sho
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
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()` instead
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.
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
64
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),
th
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)
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
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 fe
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 a/Documentation/git-bisect-lk2009.txt
b/Documen
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
f
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 archimpo
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 it's
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 +-
Documentation/gitweb.conf.txt
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 2f4ff5015..d0fe
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]: d
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 Wil
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
n
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 co
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 contai
> -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 gc.pid lock
>
> On Tue, Apr
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 the preparation repo,
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)
T
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
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 detac
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
>>> +++ b
1 - 100 of 150 matches
Mail list logo
