Actually, another reason for the latest issue was that CONTENT_LENGTH
is parsed for GET requests at all. It should be parsed only for POST
requests, or, rather, only for upoad-pack and receive-pack requests.
On Thu, Sep 06, 2018 at 11:38:31PM -0400, Jeff King wrote:
> My understanding from Jelmer's report is that a present-but-empty
> variable should be counted as "0" to mean "do not read any body bytes".
> That matches my reading of RFC 3875, which says:
>
> If no data is attached, then NULL (or
> diff --git a/read-cache.c b/read-cache.c
> index fcc776aaf0..8537a55750 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1941,20 +1941,212 @@ static void *load_index_extensions(void *_data)
> return NULL;
> }
>
> +/*
> + * A helper function that will load the specified range of
On Thu, Sep 06, 2018 at 07:53:41PM +0200, Ævar Arnfjörð Bjarmason wrote:
> I got 436 OK runs with that and 3 failures before I gave up and ctrl+c'd
> it. And the 3 failures were:
>
> t3903-stash.sh (Wstat: 256 Tests: 90 Failed: 1)
> Failed test: 55
> Non-zero exit
On Fri, Sep 07, 2018 at 06:27:40AM +0300, Max Kirillov wrote:
> On Thu, Sep 06, 2018 at 02:54:18PM -0700, Junio C Hamano wrote:
> > Max Kirillov writes:
> >> This should fix it. I'm not sure should it treat it as 0 or "-1"
> >> At least the tests mentioned by Jeff fails if I try to treat missing
According to RFC3875, empty environment variable is equivalent to unset,
and for CONTENT_LENGTH it should mean zero body to read.
However, unset CONTENT_LENGTH is also used for chunked encoding to indicate
reading until EOF. At least, the test "large fetch-pack requests can be split
across POSTs"
On Mon, Sep 03, 2018 at 06:48:54PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > And there are definitely a few nasty bits (like the way the progress is
> > ended). I'm not planning on taking this further for now, but maybe
> > you or somebody can find it interesting or useful.
>
> I think it would
On Thu, Sep 06, 2018 at 02:54:18PM -0700, Junio C Hamano wrote:
> Max Kirillov writes:
>> This should fix it. I'm not sure should it treat it as 0 or "-1"
>> At least the tests mentioned by Jeff fails if I try to treat missing
>> CONTENT_LENGTH as "-1"
>> So keep the existing behavior as much as
On Thu, Sep 06, 2018 at 04:50:33PM -0700, Jonathan Nieder wrote:
> Hi,
>
> Jeff King wrote:
>
> > But what I think is harmful is a _sorted_ list, because of the
> > "accidentally quadratic" nature, and because it's easy to call its
> > functions on an unsorted list.
>
> I agree --- in general,
Homebrew recently enabled the quarantine feature, which breaks a lot
of things [1], including installing Perforce in our macOS build jobs
on Travis CI [2], breaking all those builds in the last couple of
days.
The suggested workaround is to install affected packages using the
'--no-quarantine'
On Thu, Sep 06, 2018 at 01:54:15PM -0700, Stefan Beller wrote:
> > > It turns out we make never use of a custom compare function in
> > > the stringlist, which helps gaining confidence this use case is nowhere
> > > to be found in the code.
> >
> > Plenty of code uses the default strcmp. You can
On Wed, Sep 5, 2018 at 10:46 AM Derrick Stolee via GitGitGadget
wrote:
> Replace the BUG() statement with a die() statement, now that we
> may hit a bad pack-int-id during a 'verify' command on a corrupt
> multi-pack-index, and it is covered by a test.
>
> Signed-off-by: Derrick Stolee
> ---
>
On Wed, Sep 5, 2018 at 10:46 AM Derrick Stolee via GitGitGadget
wrote:
> Add tests that check corrupted headers in a few ways:
> [...]
> Signed-off-by: Derrick Stolee
> ---
> diff --git a/t/t5319-multi-pack-index.sh b/t/t5319-multi-pack-index.sh
> @@ -154,6 +154,51 @@ test_expect_success 'verify
On Wednesday, September 5, 2018 2:16:06 PM MST Junio C Hamano wrote:
> I think that one that is not even in 'pu' hasn't been looked at for
> a long time; it is probably a good idea to discard and replace, if
> you have something working.
I submitted a working patch set yesterday.
[1]
On Thu, Sep 06, 2018 at 03:16:21PM -0700, Stefan Beller wrote:
> > It seems funny that we'd iterate through the list checking over and over
> > whether tracing is enabled.
> >
> > Should this do:
> >
> > if (!trace_want(_default_key))
> > return;
> >
> > at the top? (Or possibly even
Hi,
Jeff King wrote:
> But what I think is harmful is a _sorted_ list, because of the
> "accidentally quadratic" nature, and because it's easy to call its
> functions on an unsorted list.
I agree --- in general, it tends to be better to build an unsorted
string list and then sort it.
Once I've
Stefan Beller wrote:
> On Wed, Sep 5, 2018 at 4:10 PM Jonathan Nieder wrote:
>> Broader comment: do you think people will be surprised by this new
>> behavior? Is there anything special we'd need to do to call it out
>> (e.g., print a warning or put something in release notes)?
>
> I guess. Not
Hi,
Max Kirillov wrote:
> According to RFC3875, empty environment variable is equivalent to unset,
> and for CONTENT_LENGTH it should mean zero body to read.
>
> However, as discussed in [1], unset CONTENT_LENGTH is also used for
> chunked encoding to indicate reading until EOF, so keep this
> > A later patch shows
> > how useful this will be.
>
> Instead of all of the above, how about being more direct, i.e. e.g.
ok.
> Conceptually, this allows string_list_clear() to be implemented in
> terms of this function, i.e.
>
> string_list_clear(struct string_list *list, int
On Thu, Sep 6, 2018 at 9:56 AM Jeff King wrote:
>
> On Thu, Sep 06, 2018 at 09:52:28AM -0700, Junio C Hamano wrote:
>
> > Stefan Beller writes:
> >
> > > It is a debugging aid, so it should print to the debugging channel.
> >
> > ... and rename it with trace_ prefix.
> >
> > Use of
Max Kirillov writes:
> According to RFC3875, empty environment variable is equivalent to unset,
> and for CONTENT_LENGTH it should mean zero body to read.
>
> However, as discussed in [1], unset CONTENT_LENGTH is also used for
> chunked encoding to indicate reading until EOF, so keep this
On Thu, Sep 6, 2018 at 2:12 PM Junio C Hamano wrote:
>
> Jonathan Nieder writes:
>
> > It seems like various commands are gaining --recurse-submodules options
> > taking different kinds of arguments:
> >
> > - clone takes --recurse-submodules=
> > - fetch takes --recurse-submodules=
> > - after
SZEDER Gábor writes:
> The test 'disable split index' in 't1700-split-index.sh' runs the
> following pipeline:
>
> cmd | grep | sed s///
>
> Drop that 'grep' from the pipeline, and let 'sed' take over its
> duties.
>
> Signed-off-by: SZEDER Gábor
> ---
Obviously good ;-) Thanks.
>
Stefan Beller writes:
> All callers use oid_to_hex to convert the desired oid to a string before
> calling submodule_move_head. Defer the conversion to the
> submodule_move_head as it will turn out to be useful in a bit.
>
> Signed-off-by: Stefan Beller
> ---
>
> This is also part of the other
Jonathan Nieder writes:
> It seems like various commands are gaining --recurse-submodules options
> taking different kinds of arguments:
>
> - clone takes --recurse-submodules=
> - fetch takes --recurse-submodules=
> - after this patch, diff takes --recurse-submodules=
>
> Is there a unifying
This patch helps address the CPU cost of loading the index by creating
multiple threads to divide the work of loading and converting the cache
entries across all available CPU cores.
It accomplishes this by having the primary thread loop across the index file
tracking the offset and (for V4
The End of Index Entry (EOIE) is used to locate the end of the variable
length index entries and the beginning of the extensions. Code can take
advantage of this to quickly locate the index extensions without having
to parse through all of the index entries.
Because it must be able to be loaded
This patch helps address the CPU cost of loading the index by loading
the cache extensions on a worker thread in parallel with loading the cache
entries.
In some cases, loading the extensions takes longer than loading the
cache entries so this patch utilizes the new EOIE to start the thread to
Optimize expand_name_field() to speed up V4 index parsing.
- strbuf_remove() in expand_name_field() is not exactly a good fit
for stripping a part at the end, _setlen() would do the same job
and is much cheaper.
- the open-coded loop to find the end of the string in
On further investigation with the previous patch, I noticed that my test
repos didn't contain the cache tree extension in their index. After doing a
commit to ensure they existed, I realized that in some instances, the time
to load the cache tree exceeded the time to load all the cache entries in
> > Does a hashmap guarantee an order?
>
> No, it definitely doesn't.
>
> I guess the reading-between-the-lines assumption that I didn't quite say
> is: I think most (if not all) of the users of sorted string lists don't
> actually care about a particular order. They just want efficient lookup.
>
On Thu, Sep 06, 2018 at 01:04:18PM -0700, Stefan Beller wrote:
> On Thu, Sep 6, 2018 at 12:12 PM Jeff King wrote:
> >
> > On Thu, Sep 06, 2018 at 10:59:42AM -0400, Jeff King wrote:
> >
> > > > + string_list_append(_list, *argv[0]);
> > >
> > > This will create an unsorted list. You'd
Junio C Hamano writes:
> I've rebuilt the collection of topics up to pk/rebase-in-c-6-final
> with these two updated series twice, once doing it manually, like I
> did the last time, and another using "rebase -i -r" on top of the
> updated pk/rebase-in-c-4-opts. The resulting trees match, of
>
It was reported that
GIT_FSMONITOR_TEST=$PWD/t7519/fsmonitor-all ./t7411-submodule-config.sh
breaks as the .gitmodules file is modified and staged after the fsmonitor
considers it clean. Mark the .gitmodules file to be not clean before
staging.
Reported-by: Ævar Arnfjörð Bjarmason
> > Ben, do you have an idea?
> >
>
> I'll take a look as soon as I can (and at the other fsmonitor test issue Ævar
> sent email about) but it may be a few days before I get a chance.
>
> I haven't had a chance to look into this yet but here are a couple of SWAG's
> I'd start with:
>
> is it
On Thu, Sep 6, 2018 at 12:12 PM Jeff King wrote:
>
> On Thu, Sep 06, 2018 at 10:59:42AM -0400, Jeff King wrote:
>
> > > + string_list_append(_list, *argv[0]);
> >
> > This will create an unsorted list. You'd have to use
> > string_list_insert() here for a sorted list, or
> >
"Johannes Schindelin via GitGitGadget"
writes:
> This patch series completes the support for all rebase options in the
> builtin rebase, e.g. --signoff, rerere-autoupdate, etc.
>
> It is based on pk/rebase -in-c-3-acts.
... which in turn was based on pk/rebase-in-c-2-basic that just got
According to RFC3875, empty environment variable is equivalent to unset,
and for CONTENT_LENGTH it should mean zero body to read.
However, as discussed in [1], unset CONTENT_LENGTH is also used for
chunked encoding to indicate reading until EOF, so keep this behavior also
for empty
On Thu, Sep 06, 2018 at 11:58:16AM +0200, Christian Couder wrote:
> On Thu, Sep 6, 2018 at 3:14 AM, Jeff King wrote:
> > On Wed, Sep 05, 2018 at 09:20:23AM +0200, Christian Couder wrote:
> >
> >> >> Thanks. I think sooner is better for this (for you or anybody else who's
> >> >> interested in
On Thu, Sep 06, 2018 at 11:51:49AM +0200, Christian Couder wrote:
> > Thanks. I signed us up as a community (making me the "coordinator" in
> > their terminology). I think the procedure is a little different this
> > year, and we actually propose projects to mentor through their system.
>
>
On 06.09.18 20:40, Junio C Hamano wrote:
Jeff King writes:
On Thu, Sep 06, 2018 at 12:16:58PM +0200, Tim Schumacher wrote:
@@ -691,17 +692,23 @@ static int run_argv(int *argcp, const char ***argv)
/* .. then try the external ones */
On Thu, Sep 06, 2018 at 03:12:03PM -0400, Jeff King wrote:
> On Thu, Sep 06, 2018 at 10:59:42AM -0400, Jeff King wrote:
>
> > > + string_list_append(_list, *argv[0]);
> >
> > This will create an unsorted list. You'd have to use
> > string_list_insert() here for a sorted list, or
> >
On Thu, Sep 06, 2018 at 09:05:50PM +0200, Tim Schumacher wrote:
> On 06.09.18 16:57, Jeff King wrote:
> > On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >
> > > If we don't have some test for these sort of aliasing loops that fails
> > > now, we really should add that
On Thu, Sep 06, 2018 at 10:59:42AM -0400, Jeff King wrote:
> > + string_list_append(_list, *argv[0]);
>
> This will create an unsorted list. You'd have to use
> string_list_insert() here for a sorted list, or
> unsorted_string_list_has_string() in the earlier call.
>
> It's
On 06.09.18 16:57, Jeff King wrote:
On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:
If we don't have some test for these sort of aliasing loops that fails
now, we really should add that in a 1/2 and fix it in this patch in 2/2.
Yes, I'd agree that this is worth
On Thu, Sep 06, 2018 at 11:40:14AM -0700, Junio C Hamano wrote:
> Also, normal users who have never seen this loop that implements
> alias expansion would not have a clue when they see "called twice".
>
> I actually think the caller should also pass cmd to run_argv() and
> then we should use it
> -Original Message-
> From: Stefan Beller
> Sent: Thursday, September 6, 2018 12:57 PM
> To: Ævar Arnfjörð Bjarmason
> Cc: Junio C Hamano ; git ; Ben
> Peart
> Subject: Re: sb/submodule-move-nested breaks t7411 under
> GIT_FSMONITOR_TEST
>
> > > Will debug further.
> >
> > I spotted
Jeff King writes:
> On Thu, Sep 06, 2018 at 12:16:58PM +0200, Tim Schumacher wrote:
>
>> @@ -691,17 +692,23 @@ static int run_argv(int *argcp, const char ***argv)
>> /* .. then try the external ones */
>> execv_dashed_external(*argv);
>>
>> -/* It could be
On Wed, Sep 5, 2018 at 4:13 PM Jonathan Nieder wrote:
>
> Stefan Beller wrote:
>
> > Many commands have flags to recurse into submodules, which is named
> > --recurse-submodules. The diff family also has a submodule recursion flag,
> > but that is named differently. Add a synonym
Many commands have flags to recurse into submodules, which is named
--recurse-submodules. The diff family also has a submodule recursion flag,
but that is named differently. Add a synonym --recurse-submodules, which
means the same as the --submodule flag, such that across all git commands
Stefan Beller writes:
> 'calculate_changed_submodule_paths' uses a local list to compute the
> changed submodules, and then produces the result by copying appropriate
> items into the result list.
>
> Instead use the result list directly and prune items afterwards
> using
On Wed, Sep 5, 2018 at 4:10 PM Jonathan Nieder wrote:
>
> Stefan Beller wrote:
>
> > Subject: submodule.sh update --remote: default to oid instead of master
>
> Yay!
>
> Nit: it wasn't clear to me at first what default this subject line was
> referring to. Perhaps:
>
> submodule update
Stefan Beller writes:
> The `changed_submodule_names` are only used for fetching, so let's make it
> part of the struct that is passed around for fetching submodules.
Yay.
Stefan Beller writes:
> Instead of sorting it after we created an unsorted list, we could insert
> correctly into the list.
It is unclear what problem you are solving, especially with
subjunctive "could" there. We are creating an unsorted list and
then sorting it and you see it as a problem
On Thu, Sep 06 2018, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Sep 06 2018, SZEDER Gábor wrote:
>
>> On Thu, Sep 06, 2018 at 02:26:49PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>>
>>> On Thu, Sep 06 2018, SZEDER Gábor wrote:
>>> > Several tests failed occasionally when the test suite was run with
Stefan Beller writes:
> The submodule subsystem is really bad at staying within 80 characters.
> Fix it while we are here.
>
> Signed-off-by: Stefan Beller
> ---
> submodule.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/submodule.c b/submodule.c
> index
Stefan Beller writes:
> All callers use oid_to_hex to convert the desired oid to a string before
> calling submodule_move_head. Defer the conversion to the
> submodule_move_head as it will turn out to be useful in a bit.
I would think this is a good change even without "as it will turn
out..."
Stefan Beller writes:
> +/* Call fn for each oid, and retain it if fn returns 0, remove it otherwise
> */
> +int oid_array_filter(struct oid_array *array,
> + for_each_oid_fn fn,
> + void *cbdata);
Comparing this with object_array_filter(), which I think this
Stefan Beller writes:
> A string list can be used as a stack, but should we?
verb missing. "We can use a string list as ..., but should we?" is
readable. "A string list can be ..., but should it be?" also is.
> A later patch shows
> how useful this will be.
Instead of all of the above, how
> > Will debug further.
>
> I spotted this again after testing the split index (see
> https://public-inbox.org/git/87va7ireuu@evledraar.gmail.com/) and
> was testing the fsmonitor test mode as well.
>
> So gentle *poke*: Did you get anywhere with debugging this? It's still
> failing on
On Thu, Sep 06, 2018 at 09:52:28AM -0700, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > It is a debugging aid, so it should print to the debugging channel.
>
> ... and rename it with trace_ prefix.
>
> Use of trace_printf() is nice, as we can control its behavior at
> runtime ;-)
Yes,
Stefan Beller writes:
> It is a debugging aid, so it should print to the debugging channel.
... and rename it with trace_ prefix.
Use of trace_printf() is nice, as we can control its behavior at
runtime ;-)
> Signed-off-by: Stefan Beller
> ---
> string-list.c | 6 +++---
> string-list.h | 4
On Thu, Sep 06, 2018 at 05:10:04PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > seen = unsorted_string_list_lookup(_list, *argv[0]);
> > if (seen) {
> > for (i = 0; i < cmd_list.nr; i++) {
> > struct string_list *item = cmd_list.items[i];
> >
> > strbuf_addf(, "
On Thursday, September 6, 2018 12:38:55 AM MST Ævar Arnfjörð Bjarmason wrote:
> On Thu, Sep 06 2018, Stephen P. Smith wrote:
> Sometimes you send mail from this address as "Stephen & Linda Smith
> ", do we also need Linda Smith's Signed-Off-By? :)
My wife and I share one email account. If I use
On Thu, Sep 06 2018, SZEDER Gábor wrote:
> On Thu, Sep 06, 2018 at 02:26:49PM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Thu, Sep 06 2018, SZEDER Gábor wrote:
>> > Several tests failed occasionally when the test suite was run with
>> > 'GIT_TEST_SPLIT_INDEX=yes'. Here are those that I
On Thu, Sep 06, 2018 at 02:26:49PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Sep 06 2018, SZEDER Gábor wrote:
> > Several tests failed occasionally when the test suite was run with
> > 'GIT_TEST_SPLIT_INDEX=yes'. Here are those that I managed to trace
> > back to this racy split index
The algorithm in can_all_from_reach_with_flags() performs a depth-
first-search, terminated by generation number, intending to use
a hueristic that "important" commits are found in the first-parent
history. This heuristic is valuable in scenarios like fetch
negotiation.
However, there is a
Signed-off-by: Derrick Stolee
---
commit-reach.c | 8
1 file changed, 8 insertions(+)
diff --git a/commit-reach.c b/commit-reach.c
index 0fc3b1ac18..0a75644653 100644
--- a/commit-reach.c
+++ b/commit-reach.c
@@ -563,6 +563,7 @@ int can_all_from_reach_with_flag(struct object_array
Signed-off-by: Derrick Stolee
---
commit-reach.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/commit-reach.c b/commit-reach.c
index ee374dce20..0fc3b1ac18 100644
--- a/commit-reach.c
+++ b/commit-reach.c
@@ -481,6 +481,7 @@ static enum contains_result
Signed-off-by: Derrick Stolee
---
t/helper/test-tool.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/t/helper/test-tool.c b/t/helper/test-tool.c
index 7566b0786a..f70d5d74f8 100644
--- a/t/helper/test-tool.c
+++ b/t/helper/test-tool.c
@@ -1,5 +1,6 @@
#include "git-compat-util.h"
The trace2 facility allows tracing category-key-value triples that
we can use to communicate runtime information to a side channel.
One use is to track the number of commits that are walked by a
graph algorithm.
Add run_and_check_trace2 test function to run a given command with
paint_down_to_common() is used by many Git commands, and sometimes
multiple times in a single call. It is important to measure
performance of this method, but the actual time it takes can vary
due to interactions outside Git's control (file system, CPU
contention, etc.). Instead, count how many
As promised, here is the direction I took when applying the trace2
feature to the walking code in commit-reach.c. Hence, this depends
on Jeff's trace2 patches and ds/reachable.
There are multiple benefits to the approach I take here:
1. If a user has performance problems, we can rerun the
On Thu, Sep 06 2018, Jeff King wrote:
> On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> If we don't have some test for these sort of aliasing loops that fails
>> now, we really should add that in a 1/2 and fix it in this patch in 2/2.
>
> Yes, I'd agree that this
Greetings,
I am a broker linked with high profile private investors from the Arabian
Gulf,Asia and Europe, who are interested and willing to fund you in any current
project you are undergoing, My clients are privately seeking means of expanding
their investment portfolio global.
they are
On Thu, Sep 06, 2018 at 12:16:58PM +0200, Tim Schumacher wrote:
> @@ -691,17 +692,23 @@ static int run_argv(int *argcp, const char ***argv)
> /* .. then try the external ones */
> execv_dashed_external(*argv);
>
> - /* It could be an alias -- this works
On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:
> If we don't have some test for these sort of aliasing loops that fails
> now, we really should add that in a 1/2 and fix it in this patch in 2/2.
Yes, I'd agree that this is worth adding a test (especially if the
output
On Wed, Sep 05 2018, Tim Schumacher wrote:
> On 05.09.18 19:34, Jeff King wrote:
>>
>> It could also extend to ! aliases if we wanted (i.e., my '!git foo'
>> example from earlier), but you'd have to carry the counter through the
>> environment between processes.
>
> That is a question about
On Thu, Sep 06 2018, Tim Schumacher wrote:
> Aliases can only contain non-alias git commands and their
> arguments, not other user-defined aliases. Resolving further
> (nested) aliases is prevented by breaking the loop after the
> first alias was processed. Git then fails with a
On Wed, Sep 05 2018, Tim Schumacher wrote:
> On 05.09.18 19:34, Jeff King wrote:
>> On Wed, Sep 05, 2018 at 10:54:27AM +0200, Tim Schumacher wrote:
>>
>>> Aliases can only contain non-alias git commands and their
>>> arguments, not other user-defined aliases. Resolving further
>>> (nested)
On Thu, Feb 01 2018, Ævar Arnfjörð Bjarmason wrote:
> The GIT_FSMONITOR_TEST variable allows you to roundtrip the fsmonitor
> codpath in the whole test suite. On both Debian & CentOS this breaks for
> me:
>
> (cd t && GIT_FSMONITOR_TEST=$PWD/t7519/fsmonitor-all
>
On Fri, May 25 2018, Stefan Beller wrote:
> On Fri, May 25, 2018 at 5:28 AM, Ævar Arnfjörð Bjarmason
> wrote:
>>
>> On Thu, May 17 2018, Junio C Hamano wrote:
>>
>>> * sb/submodule-move-nested (2018-03-29) 6 commits
>>> (merged to 'next' on 2018-04-25 at 86b177433a)
>>> + submodule: fixup
On Thu, Sep 06 2018, SZEDER Gábor wrote:
> Ever since the split index feature was introduced [1], refreshing a
> split index is prone to a variant of the classic racy git problem.
>
> Consider the following sequence of commands updating the split index
> when the shared index contains a racily
On Thu, Sep 06 2018, SZEDER Gábor wrote:
> t3903-stash.sh:
> https://travis-ci.org/git/git/jobs/385542084#L5858
>
> t4024-diff-optimize-common.sh:
> https://travis-ci.org/git/git/jobs/386531969#L3174
>
> t4015-diff-whitespace.sh:
>
Aliases can only contain non-alias git commands and their
arguments, not other user-defined aliases. Resolving further
(nested) aliases is prevented by breaking the loop after the
first alias was processed. Git then fails with a command-not-found
error.
Allow resolving nested aliases by not
On Thu, Sep 6, 2018 at 3:14 AM, Jeff King wrote:
> On Wed, Sep 05, 2018 at 09:20:23AM +0200, Christian Couder wrote:
>
>> >> Thanks. I think sooner is better for this (for you or anybody else who's
>> >> interested in mentoring). The application period opens on September
>> >> 10th, but I think
On Thu, Sep 6, 2018 at 3:21 AM, Jeff King wrote:
> On Mon, Sep 03, 2018 at 06:36:19AM +0200, Christian Couder wrote:
>
>> So here is a landing page for the next Outreachy round:
>>
>> https://git.github.io/Outreachy-17/
>>
>> about the microprojects I am not sure which page I should create or
On Thu, Sep 06 2018, SZEDER Gábor wrote:
> On Thu, Sep 06, 2018 at 10:02:43AM +0200, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Thu, Sep 06 2018, SZEDER Gábor wrote:
>>
>> > +# Create a file named as $1 with content read from stdin.
>> > +# Set the file's mtime to a few seconds in the past to
On Thu, Sep 06, 2018 at 10:02:43AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Thu, Sep 06 2018, SZEDER Gábor wrote:
>
> > +# Create a file named as $1 with content read from stdin.
> > +# Set the file's mtime to a few seconds in the past to avoid racy
> > situations.
> > +create_file () {
>
On Thu, Sep 06 2018, SZEDER Gábor wrote:
> '
>
> +
^ stray newline being added here that shouldn't be added.
On Thu, Sep 06 2018, SZEDER Gábor wrote:
> +# Create a file named as $1 with content read from stdin.
> +# Set the file's mtime to a few seconds in the past to avoid racy situations.
> +create_file () {
Nit: Would be easier to read in the future as
e.g. s/create_file/create_old_file/ or
On Thu, Sep 06 2018, Stephen P. Smith wrote:
This all looks good to me this time around.
> Stephen P. Smith (4):
> Move has_unmerged earlier in the file.
> wt-status: rename commitable to committable
> t7501: add test of "commit --dry-run --short"
> wt-status.c: Set the committable
> + if (repo_submodule_init(, the_repository, path) < 0)
> + warning(_("Could not get submodule repository for submodule
> 's'"), path);
Missing "%" in format specifier, so `path` will never be used. Also,
s/C/c/ at the start of the warning.
Thanks for marking with _().
On Thu, 6 Sep 2018 at 00:59, Stefan Beller wrote:
>
> --submodule[=]::
Maybe drop `--submodule` here ...
> +--recurse-submodules[=]::
> Specify how differences in submodules are shown. When specifying
> `--submodule=short` the 'short' format is used. This format just
... and
Hi,
Jelmer Vernooij wrote[1]:
> Git's http-backend has become slightly stricter about the content
> of the CONTENT_LENGTH variable. Previously, Dulwich would leave this
> variable empty but git now expects it to be set to 0 for GET requests
> without a body.
>
> I'm uploading a fixed version of
On Wednesday, September 5, 2018 9:17:29 PM MST Stephen & Linda Smith wrote:
> So two questions:
> 1) why would git version 2.18.0 not appear to continue applying the
> patches.
>
> 2) where do I find the command "git mailsplit". The onlything in my
> installed tree is:
>
Never mind, I
96 matches
Mail list logo
