Hello!
Recent versions of git are failing the testsuite on big-endian targets
such as s390x in Debian.
Build logs are:
> https://buildd.debian.org/status/fetch.php?pkg=git&arch=s390x&ver=1%3A2.23.0%7Erc0-1&stamp=1564449102&raw=0
> https://buildd.debian.org/status/fetch.php?pkg=git&arch=s390x&ver
Jeff King wrote:
> On Tue, Jul 30, 2019 at 09:59:17PM -0400, Todd Zullinger wrote:
>> At the risk of showing my complete lack of knowledge about
>> these tests, I was wondering if the order mattered for the
>> other tests in t0011 and t0016.
[...]
>> You've got a more comprehensive patch and a prop
On Wed, Jul 10, 2019 at 11:39:37PM +, brian m. carlson wrote:
> This is a bug. If the destination side of a refspec is omitted, and the
> source side resolves to a ref starting with "refs/heads/" or
> "refs/tags/" (which I expect it does here), then that ref is used as the
> destination.
>
>
Commit 7328482253 (repack: disable bitmaps-by-default if .keep files
exist, 2019-06-29) taught repack to prefer disabling bitmaps to
duplicating objects (unless bitmaps were asked for explicitly).
But there's an easier way to do this: if we keep passing the
--honor-pack-keep flag to pack-objects w
Depending on various config options, a full repack may not be able to
build a reachability bitmap index (e.g., if pack.packSizeLimit forces us
to write multiple packs). In these cases pack-objects may write a
warning to stderr.
Since 36eba0323d (repack: enable bitmaps by default on bare repos,
201
After our test snippet finishes, the .keep file is left in place, making
it hard to do further tests of the auto-bitmap-writing code (since it
suppresses the feature completely). Let's clean it up.
Signed-off-by: Jeff King
---
t/t7700-repack.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a
On Wed, Jul 31, 2019 at 12:28:07AM -0400, Jeff King wrote:
> On Mon, Jul 29, 2019 at 02:50:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> > > Instead, it may make sense to turn the --write-bitmap-index option of
> > > pack-objects into a tri-state: true/false/auto. Then pack-objects would
> > > k
We store and manipulate the cumulative traverse_info.pathlen as an
"int", which can overflow when we are fed ridiculously long pathnames
(e.g., ones at the edge of 2GB or 4GB, even if the individual tree entry
names are smaller than that). The results can be confusing, though
after some prodding I
We take a "struct name_entry", but only care about the length of the
path name. Let's just take that length directly, making it easier to use
the function from callers that sometimes do not have a name_entry at
all.
Signed-off-by: Jeff King
---
builtin/merge-tree.c | 2 +-
tree-walk.h |
As the previous commit shows, the presence of an oid in each level of
the traverse_info is confusing and ultimately not necessary. Let's drop
it to make it clear that it will not always be set (as well as convince
us that it's unused, and let the compiler catch any merges with other
branches that d
All but one of the callers of make_traverse_path() allocate a new heap
buffer to store the path. Let's give them an easy way to write to a
strbuf, which saves them from computing the length themselves (which is
especially tricky when they want to add to the path). It will also make
it easier for us
The make_traverse_path() function isn't very careful about checking its
output buffer boundaries. In fact, it doesn't even _know_ the size of
the buffer it's writing to, and just assumes that the caller used
traverse_path_len() correctly. And even then we assume that our
traverse_info.pathlen compo
We assume that if setup_traverse_info() is passed a non-empty "base"
string, that string is pointing into a tree object and we can read the
object oid by skipping past the trailing NUL.
As it turns out, this is not true for either of the two calls, and we
may end up reading garbage bytes:
1. In
I noticed that it's possible to get funny integer over/underflows with
tree-walk's traverse_info (with specially-crafted absurdly-sized tree
paths). I wasn't able to turn this into an actual buffer overflow
because the funky sizes cause allocation failures way before we ever get
into make_traverse_
On Wed, Jul 31, 2019 at 06:06:02AM +0200, René Scharfe wrote:
> Am 31.07.19 um 05:27 schrieb Jeff King:
> > One thing that makes it all a bit funky is that the "put" lines also
> > output the old value (which is what all those NULLs) are. And I think
> > that solves my "value3" puzzlement from ear
On Mon, Jul 29, 2019 at 02:50:56PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Instead, it may make sense to turn the --write-bitmap-index option of
> > pack-objects into a tri-state: true/false/auto. Then pack-objects would
> > know that we are in best-effort mode, and would avoid warning in that
>
On Fri, May 10, 2019 at 01:20:55AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > Michael Haggerty and I have (off-list) discussed variations on that, but
> > it opens up a lot of new issues. Moving something into quarantine isn't
> > atomic. So you've still corrupted the repo, but now it's recoverabl
Am 31.07.19 um 05:27 schrieb Jeff King:
> One thing that makes it all a bit funky is that the "put" lines also
> output the old value (which is what all those NULLs) are. And I think
> that solves my "value3" puzzlement from earlier. It is not part of the
> iteration at all, but rather the result o
On Tue, Jul 30, 2019 at 11:27:35PM -0400, Jeff King wrote:
> That would perhaps be clearer if the "hashmap" tool actually did the
> sorting itself (so we'd sort _just_ the iteration, not the whole
> output). Something like this, though I'm on the fence about whether it
> is worth it:
> [...]
And
On Tue, Jul 30, 2019 at 09:59:17PM -0400, Todd Zullinger wrote:
> At the risk of showing my complete lack of knowledge about
> these tests, I was wondering if the order mattered for the
> other tests in t0011 and t0016. I had assumed it didn't and
> had something like this for testing (and a simi
Thanks for your last email response to me.
The information required should include the following-:
Your full names
Your address
Telephone number
Your private email
Occupation
AgeThis is to enable my further discussion with you in confidence.
Best regards and wishes to you.
Philip Twite
REPLY TO
cha
Jeff King wrote:
> On Tue, Jul 30, 2019 at 08:59:33PM -0400, Jeff King wrote:
>
>>> OTOH, this is not just any hashmap, but an oidmap, and I could imagine
>>> that there might be use cases where it would be beneficial if the
>>> iteration order were to match the oid order (but don't know whether w
30.07.2019, 13:37, "Philip McGraw" :
> python os.remove() throws exceptions on Windows platform when attempting
> to remove file while it is still open. Need to grab filename while file open,
> close file handle, then remove by name. Apparently other platforms are more
> permissive of removing f
On Tue, Jul 30, 2019 at 09:23:36PM -0400, Jeff King wrote:
> test_expect_success 'iterate (case insensitive)' '
> -
> -test_hashmap "put key1 value1
> -put key2 value2
> -put fooBarFrotz value3
> -iterate" "NULL
> -NULL
> -NULL
> -fooBarFrotz value3
> -key2 value2
> -key1 value1" ignorecase
By t
On Tue, Jul 30, 2019 at 08:59:33PM -0400, Jeff King wrote:
> > OTOH, this is not just any hashmap, but an oidmap, and I could imagine
> > that there might be use cases where it would be beneficial if the
> > iteration order were to match the oid order (but don't know whether we
> > actually have s
On Tue, Jul 30, 2019 at 03:56:43PM -0700, Andrey Vagin wrote:
> On Tue, Jul 30, 2019 at 3:13 PM Junio C Hamano wrote:
> >
> > Dmitry Safonov writes:
> >
> > > I was almost certain that git won't let me send the same patch twice,
> >
> > Why? And more importantly, does it matter to readers of th
On Tue, Jul 30, 2019 at 10:56:24PM +0200, SZEDER Gábor wrote:
> > Ah, of course. Our oid hashing is done by just picking off the first
> > bytes of the sha1, and it doesn't care about endianness (because these
> > are just internal-to-memory hashes).
>
> Yeah.
>
> > We _could_ reconcile that lik
De: José Luiz Fabris
Enviado: terça-feira, 30 de julho de 2019 18:37
Para: José Luiz Fabris
Assunto: PROPOSAL.
Good Day,
I am Mrs.Margaret Ko May-Yee Leung Deputy Managing Director and Executive
Director of Chong Hing Bank Limited. I write briefly to
On Tue, Jul 30, 2019 at 5:04 PM Junio C Hamano wrote:
>
> Matheus Tavares writes:
>
> > @@ -475,7 +475,7 @@ static int grep_submodule(struct grep_opt *opt,
> > strbuf_release(&base);
> > free(data);
> > } else {
> > - hit = grep_cache(&subopt, pathspe
Hi Junio,
On 7/30/19 11:13 PM, Junio C Hamano wrote:
> Dmitry Safonov writes:
>
>> I was almost certain that git won't let me send the same patch twice,
>
> Why? And more importantly, does it matter to readers of this
> message what you thought?
I see the point of putting description in imper
On Tue, Jul 30, 2019 at 3:13 PM Junio C Hamano wrote:
>
> Dmitry Safonov writes:
>
> > I was almost certain that git won't let me send the same patch twice,
>
> Why? And more importantly, does it matter to readers of this
> message what you thought?
Sounds rude. What matter to readers except au
Dmitry Safonov writes:
> I was almost certain that git won't let me send the same patch twice,
Why? And more importantly, does it matter to readers of this
message what you thought?
> but today I've managed to double-send a directory by a mistake:
> git send-email --to linux-ker...@vger.
On 2019.07.30 14:00, Jeff Hostetler wrote:
>
>
> On 7/29/2019 6:20 PM, Josh Steadmon wrote:
> > trace2 can write files into a target directory. With heavy usage, this
> > directory can fill up with files, causing difficulty for
> > trace-processing systems.
>
> I'm routing data in my org to a da
On 2019.07.30 12:46, Jeff Hostetler wrote:
[snip]
> Also release sentinel_path ?
> (And in both of the return statements below.)
Thanks for the catch. Fixed in V2.
On Tue, Jul 30, 2019 at 10:04 PM Junio C Hamano wrote:
>
> Matheus Tavares writes:
> > @@ -598,7 +599,8 @@ static int grep_tree(struct grep_opt *opt, const struct
> > pathspec *pathspec,
> > free(data);
> > } else if (recurse_submodules && S_ISGITLINK(entry.m
On 2019.07.30 12:46, Jeff Hostetler wrote:
>
>
> On 7/29/2019 6:20 PM, Josh Steadmon wrote:
> > trace2 can write files into a target directory. With heavy usage, this
> > directory can fill up with files, causing difficulty for
> > trace-processing systems.
> >
> > When trace2 would write a file
On 2019.07.30 09:29, Derrick Stolee wrote:
> On 7/29/2019 6:20 PM, Josh Steadmon wrote:
> > trace2 can write files into a target directory. With heavy usage, this
> > directory can fill up with files, causing difficulty for
> > trace-processing systems.
> >
> > When trace2 would write a file to a
On Tue, Jul 30, 2019 at 11:29:15PM +0200, SZEDER Gábor wrote:
> The test '--no-show-forced-updates' in 't5510-fetch.sh' added in
> cdbd70c437 (fetch: add --[no-]show-forced-updates argument,
> 2019-06-18) runs '! test_i18ngrep ...'. This is wrong, because when
> running the test with GIT_TEST_GETT
The test '--no-show-forced-updates' in 't5510-fetch.sh' added in
cdbd70c437 (fetch: add --[no-]show-forced-updates argument,
2019-06-18) runs '! test_i18ngrep ...'. This is wrong, because when
running the test with GIT_TEST_GETTEXT_POISON=true, then
'test_i18ngrep' is basically a noop and always r
I was almost certain that git won't let me send the same patch twice,
but today I've managed to double-send a directory by a mistake:
git send-email --to linux-ker...@vger.kernel.org /tmp/timens/
--cc 'Dmitry Safonov <0x7f454...@gmail.com>' /tmp/timens/`
[I haven't noticed that
On 7/30/19 10:10 PM, SZEDER Gábor wrote:
> On Tue, Jul 30, 2019 at 09:33:27PM +0100, Dmitry Safonov wrote:
>> @@ -589,6 +591,19 @@ test_expect_success $PREREQ 'In-Reply-To with
>> --chain-reply-to' '
>> test_cmp expect actual
>> '
>>
>> +test_expect_success $PREREQ 'ask confirmation for do
On Tue, Jul 30, 2019 at 09:33:27PM +0100, Dmitry Safonov wrote:
> @@ -589,6 +591,19 @@ test_expect_success $PREREQ 'In-Reply-To with
> --chain-reply-to' '
> test_cmp expect actual
> '
>
> +test_expect_success $PREREQ 'ask confirmation for double-send' '
> + clean_fake_sendmail &&
> +
"Derrick Stolee via GitGitGadget" writes:
> diff --git a/Documentation/config/feature.txt
> b/Documentation/config/feature.txt
> new file mode 100644
> index 00..f74314ae90
> --- /dev/null
> +++ b/Documentation/config/feature.txt
> @@ -0,0 +1,15 @@
> +feature.*::
> +...
> +* `gc.writeCom
On Tue, Jul 30, 2019 at 04:02:03PM -0400, Jeff King wrote:
> On Tue, Jul 30, 2019 at 03:49:38PM -0400, Todd Zullinger wrote:
>
> > > Subtest 6 had an ordering issue. We do not know whether
> > > the problem is the code or the test result not keeping up
> > > with the code changes.
> > >
> > > ---
"Derrick Stolee via GitGitGadget" writes:
> diff --git a/repository.h b/repository.h
> index 4fb6a5885f..2bb2bc3eea 100644
> --- a/repository.h
> +++ b/repository.h
> @@ -4,6 +4,7 @@
> #include "path.h"
>
> struct config_set;
> +struct repo_settings;
Given that the next hunk you introduce th
Jeff King writes:
> @@ -116,19 +116,11 @@ unsigned int memihash_cont(unsigned int hash_seed,
> const void *buf, size_t len);
> * Converts a cryptographic hash (e.g. SHA-1) into an int-sized hash code
> * for use in hash tables. Cryptographic hashes are supposed to have
> * uniform distribu
I was almost certain that git won't let me send the same patch twice,
but today I've managed to double-send a directory by a mistake:
git send-email --to linux-ker...@vger.kernel.org /tmp/timens/
--cc 'Dmitry Safonov <0x7f454...@gmail.com>' /tmp/timens/`
[I haven't noticed that
On July 30, 2019 3:50 PM, Todd Zullinger wrote:
> To: Randall S. Becker
> Cc: 'Junio C Hamano' ; Christian Couder
> ; SZEDER Gábor ; Jeff
> King ; git@vger.kernel.org; git-
> packag...@googlegroups.com
> Subject: Re: [ANNOUNCE] Git v2.23.0-rc0 - Initial test failures on NonStop
>
> Hi,
>
> [adde
On 7/30/19 8:35 PM, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>> On Tue, Jul 30, 2019 at 05:26:24PM +0100, Dmitry Safonov wrote:
>>> + if (@dupes) {
>>> + printf(__("Patches specified several times: \n"));
>>
>> Is this message translated? (I don't know what __("") does in
>> Pe
On July 30, 2019 3:45 PM, Jeff King wrote:
> To: Randall S. Becker
> Cc: 'Junio C Hamano' ; git@vger.kernel.org; git-
> packag...@googlegroups.com
> Subject: Re: [ANNOUNCE] Git v2.23.0-rc0 - Initial test failures on NonStop
>
> On Tue, Jul 30, 2019 at 01:08:37PM -0400, Randall S. Becker wrote:
>
Hello Dear Friend.
I’m Mrs. Stellar Maoris a manger in HSBC bank of Spain Madrid, I am
sending
this brief letter to seek for your partnership and long term relationship,
I have an important and urgent issue I want to discuss with you privately about
Transaction fund worth the sum of $9.5
Matheus Tavares writes:
> @@ -475,7 +475,7 @@ static int grep_submodule(struct grep_opt *opt,
> strbuf_release(&base);
> free(data);
> } else {
> - hit = grep_cache(&subopt, pathspec, 1);
> + hit = grep_cache(&subopt, pathspec, cached);
>
On Tue, Jul 30, 2019 at 03:49:38PM -0400, Todd Zullinger wrote:
> > Subtest 6 had an ordering issue. We do not know whether
> > the problem is the code or the test result not keeping up
> > with the code changes.
> >
> > --- expect 2019-07-30 16:56:36 +
> > +++ actual 2019-07-30 16:5
Hi,
[added Christian, SZEDER, and Jeff to Cc as author and
helpers on the newly-added t0016-oidmap]
Randall S. Becker wrote:
> A preview of the situation with testing 2.23.0.rc0 on
> NonStop is not great. We have had some new failures right
> off the bat on our NonStop platforms. This is a previe
On Tue, Jul 30, 2019 at 01:08:37PM -0400, Randall S. Becker wrote:
> t0016: oidmap
>
> Subtest 6 had an ordering issue. We do not know whether the problem is the
> code or the test result not keeping up with the code changes.
> --- expect 2019-07-30 16:56:36 +
> +++ actual 2019-07-
From: Derrick Stolee
The core.untrackedCache config setting is slightly complicated,
so clarify its use and centralize its parsing into the repo
settings.
The default value is "keep" (returned as -1), which persists the
untracked cache if it exists.
If the value is set as "false" (returned as 0
SZEDER Gábor writes:
> On Tue, Jul 30, 2019 at 05:26:24PM +0100, Dmitry Safonov wrote:
>> +if (@dupes) {
>> +printf(__("Patches specified several times: \n"));
>
> Is this message translated? (I don't know what __("") does in
> Perl.) If it is, then ...
That's not "in Perl" per
From: Derrick Stolee
The 'feature.experimental' setting includes config options that are
not committed to become defaults, but could use additional testing.
Update the following config settings to take new defaults, and to
use the repo_settings struct if not already using them:
* 'pack.useSpars
From: Derrick Stolee
There are a few important config settings that are not loaded
during git_default_config. These are instead loaded on-demand.
Centralize these config options to a single scan, and store
all of the values in a repo_settings struct. The values for
each setting are initialized a
This is a brand-new thread to replace ds/early-access. The discussion on
that thread was very helpful [1].
With this in mind, I propose instead a set of "feature.*" config settings
that form groups of "community recommended" settings (with some caveats). In
the space below, I'll list a set of poss
From: Derrick Stolee
When a repo has many commits, it is helpful to write and read the
commit-graph file. Future changes to Git may include new config
settings that are beneficial in this scenario.
Create the 'feature.manyCommits' config setting that changes the
default values of 'core.commitGra
From: Derrick Stolee
The feature.manyFiles setting is suitable for repos with many
files in the working directory. By setting index.version=4 and
core.untrackedCache=true, commands such as 'git status' should
improve.
While adding this setting, modify the index version precedence
tests to check
On Tue, Jul 30, 2019 at 05:26:24PM +0100, Dmitry Safonov wrote:
> + if (@dupes) {
> + printf(__("Patches specified several times: \n"));
Is this message translated? (I don't know what __("") does in
Perl.) If it is, then ...
> @@ -589,6 +591,19 @@ test_expect_success $PREREQ 'In
Hi Andreas
On 30/07/2019 18:24, Andreas Wiesinger wrote:
Hello,
git revert for merges will mark merged files as deleted and commit
them as if they would have been deleted, but that is for sure never
what anybody would expect and has deleted many files unintentionally
and unrecognized in our rep
"Randall S. Becker" writes:
> On July 30, 2019 1:32 PM, Junio C Hamano wrote:
>>
>> I wonder if a tool like sparse can help us catch a pattern that feeds
> errno to
>> "%d" format.
>> ...
> Seems reasonable. Better than trying to use strerror(), which previously
> (I'm not sure whether it was t
On July 30, 2019 1:32 PM, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> > t0066: dir-iterator
> >
> > Subtest 4 depends on a non-portable error code. ENOENT is not
> guaranteed ...
> > Subtest 5 also depends on a non-portable error code. ENOTDIR is not
gua...
>
> Yikes, and sorry. I'v
Hi, Junio and Randall
On Tue, Jul 30, 2019 at 2:31 PM Junio C Hamano wrote:
>
> "Randall S. Becker" writes:
>
> > t0066: dir-iterator
> >
> > Subtest 4 depends on a non-portable error code. ENOENT is not guaranteed ...
> > Subtest 5 also depends on a non-portable error code. ENOTDIR is not gua..
On 7/29/2019 6:20 PM, Josh Steadmon wrote:
trace2 can write files into a target directory. With heavy usage, this
directory can fill up with files, causing difficulty for
trace-processing systems.
I'm routing data in my org to a daemon via a Named Pipe or UD Socket,
so I'm not seeing the tho
Am 30.07.19 um 02:49 schrieb Carlo Arenas:
> On Mon, Jul 29, 2019 at 10:47 AM Junio C Hamano wrote:
>> René Scharfe writes:
+pcre.jit::
+If set to false, disable JIT when using PCRE. Defaults to
+true.
+if set to -1 will try first to use JIT and fallback to the
>>
python os.remove() throws exceptions on Windows platform when attempting
to remove file while it is still open. Need to grab filename while file open,
close file handle, then remove by name. Apparently other platforms are more
permissive of removing files while busy.
reference: https://docs.pytho
"Randall S. Becker" writes:
> t0066: dir-iterator
>
> Subtest 4 depends on a non-portable error code. ENOENT is not guaranteed ...
> Subtest 5 also depends on a non-portable error code. ENOTDIR is not gua...
Yikes, and sorry. I've become somewhat complacent after relying on
how good our other r
Hello,
git revert for merges will mark merged files as deleted and commit
them as if they would have been deleted, but that is for sure never
what anybody would expect and has deleted many files unintentionally
and unrecognized in our repo shortly.
I have reproduced this issue in a very small exa
Hi All,
A preview of the situation with testing 2.23.0.rc0 on NonStop is not great. We
have had some new failures right off the bat on our NonStop platforms. This is
a preview of what we find within the first bit of testing. The tests run a long
time, so more to come.
t0016: oidmap
Subtest 6
Running git-grep with --recurse-submodules results in a cached grep for
the submodules even when --cached is not used. This makes all
modifications in submodules' tracked files be always ignored when
grepping. Solve that making git-grep respect the cached option when
invoking grep_cache() inside gr
Am 30.07.19 um 02:08 schrieb Carlo Arenas:
> On Mon, Jul 29, 2019 at 1:35 PM René Scharfe wrote:
>>
>> Am 28.07.19 um 03:41 schrieb Carlo Arenas:
>>> On Sat, Jul 27, 2019 at 4:48 PM Ævar Arnfjörð Bjarmason
>>> wrote:
> + free((void *)p->pcre_tables);
Is the cast really needed? I
On 7/29/2019 6:20 PM, Josh Steadmon wrote:
trace2 can write files into a target directory. With heavy usage, this
directory can fill up with files, causing difficulty for
trace-processing systems.
When trace2 would write a file to a target directory, first check
whether or not the directory i
I was almost certain that git won't let me send the same patch twice,
but today I've managed to double-send a directory by a mistake:
git send-email --to linux-ker...@vger.kernel.org /tmp/timens/
--cc 'Dmitry Safonov <0x7f454...@gmail.com>' /tmp/timens/`
[I haven't noticed that
On 7/29/2019 6:20 PM, Josh Steadmon wrote:
> trace2 can write files into a target directory. With heavy usage, this
> directory can fill up with files, causing difficulty for
> trace-processing systems.
>
> When trace2 would write a file to a target directory, first check
> whether or not the dire
Here is the test coverage report for the changes in v2.23.0-rc0 since v2.22.0.
Thanks,
-Stolee
[1] https://derrickstolee.github.io/git-test-coverage/reports/v2.23.0-rc0.htm
[2] https://derrickstolee.github.io/git-test-coverage/reports/v2.23.0-rc0.txt
---
apply.c
85c3713d 1187) cp = skip_tree_pr
Here is today's test coverage report.
Thanks,
-Stolee
[1] https://derrickstolee.github.io/git-test-coverage/reports/2019-07-30.htm
[2] https://derrickstolee.github.io/git-test-coverage/reports/2019-07-30.txt
---
pu fb32a9d64339806dc739b6bb31cfd2c975625636
jch bef7796fdcfab7f3792366a567
On Mon, Jul 29, 2019 at 5:38 AM Ævar Arnfjörð Bjarmason
wrote:
> On Mon, Jul 29 2019, Carlo Arenas wrote:
> > On Mon, Jul 29, 2019 at 1:55 AM Ævar Arnfjörð Bjarmason
> > wrote:
> >>
> >> On Mon, Jul 29 2019, Carlo Marcelo Arenas Belón wrote:
> >>
> >> > PCRE1 allowed for a compile time flag to di
On 7/30/19 12:54 PM, Ævar Arnfjörð Bjarmason wrote:
>
> On Tue, Jul 30 2019, Dmitry Safonov wrote:
>
>> I was almost certain that git won't let me send the same patch twice,
>> but today I've managed to double-send a directory by a mistake:
>> git send-email --to linux-ker...@vger.kernel.org
On Tue, Jul 30 2019, Dmitry Safonov wrote:
> I was almost certain that git won't let me send the same patch twice,
> but today I've managed to double-send a directory by a mistake:
> git send-email --to linux-ker...@vger.kernel.org /tmp/timens/
> --cc 'Dmitry Safonov <0x7f454...@
On Tue, Jul 30, 2019 at 4:49 AM Junio C Hamano wrote:
> * nd/index-dump-in-json (2019-06-26) 11 commits
> - SQUASH???
> - t3008: use the new SINGLE_CPU prereq
> - read-cache.c: dump "IEOT" extension as json
> - read-cache.c: dump "EOIE" extension as json
> - resolve-undo.c: dump "REUC" extens
On Tue, 30 Jul 2019 at 01:43, Josh Steadmon wrote:
>
> On 2019.07.29 22:04, Martin Ågren wrote:
> > This script seems to me like if it passes 100%, we can be fairly sure
> > we're ok, but [...]
> Will squash these as you said in V3. Will also think about whether
> another test approach would make
85 matches
Mail list logo
