Hello,
On Wed, Jul 31, 2019 at 10:21 PM Junio C Hamano wrote:
>
> Jeff King writes:
>
> > This seems OK to me, though I kind of wonder if anybody really wants
> > "auto". Unlike log.decorate, which changes the syntax, there is no real
> > reason to avoid mailmap when somebody else is parsing the
Jeff King writes:
> This seems OK to me, though I kind of wonder if anybody really wants
> "auto". Unlike log.decorate, which changes the syntax, there is no real
> reason to avoid mailmap when somebody else is parsing the output. And I
> could imagine it is especially confusing if:
>
> git log
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
On Wed, Jul 31, 2019 at 12:57 PM Junio C Hamano wrote:
>
> Christian Couder writes:
>
> > 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,
>
On Wed, Jul 31, 2019 at 08:38:14PM -0500, Ariadne Conill wrote:
> > Something like:
> >
> > Author: A U Thor
> > Original-Author: I M Mailmapped
> >
> > gives even more information while leaving the "Author:" line untouched.
> > But in introducing a new line, it may also be breaking somebody
Recently, someone[0] pointed out to me that am-based rebases don't apply
smudge and clean filters on the final checkout.
Reproduction:
-
#!/bin/sh -e
mkdir test-repo
cd test-repo
git init
git config filter.test.clean "sed -e 's/smudged/clean/g'"
git config filter.test.smudge "sed -e 's/clean/
Hello,
On Wed, Jul 31, 2019 at 8:00 PM Jeff King wrote:
>
> On Wed, Jul 31, 2019 at 05:21:25PM -0700, Jonathan Nieder wrote:
>
> > Although as Dscho mentions, it's particularly irritating because it is
> > not part of the paginated output.
> >
> > I wonder if the ideal might not be to trigger it
31.07.2019, 20:36, "Philip McGraw via GitGitGadget" :
> python os.remove() throws exceptions on Windows platform when attempting to
> remove file while still open.
>
> Add local allocateTempFileName() to clarify that only the name is being
> allocated by NamedTemporaryFile(); file and handle are
31.07.2019, 17:52, "Philip McGraw" :
> 2019.07.31 10:09 Andrey
>> 31.07.2019, 09:53, "Philip McGraw" :
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
Jeff King wrote:
> This seems OK to me, though I kind of wonder if anybody really wants
> "auto".
Sure. It's just the usual way of handling the lack of support for an
"unset" directive in git's config syntax (for example, if a script
author wants to test the default behavior).
Thanks,
Jonathan
On Wed, Jul 31, 2019 at 5:43 AM Johannes Schindelin
wrote:
>
> Hi,
>
> On Mon, 29 Jul 2019, Junio C Hamano wrote:
>
> > An early preview release Git v2.23.0-rc0 is now available for
> > testing at the usual places. It is comprised of 420 non-merge
> > commits since v2.22.0, contributed by 62 peop
On Wed, Jul 31, 2019 at 05:21:25PM -0700, Jonathan Nieder wrote:
> Although as Dscho mentions, it's particularly irritating because it is
> not part of the paginated output.
>
> I wonder if the ideal might not be to trigger it more selectively, when
> the output actually changed due to a reflog e
On Wed, Jul 31, 2019 at 07:12:57PM -0400, Jeff King wrote:
> Hrm. But common-main calls initialize_the_repository(), which points it
> at &the_repo. And I can't find any other assignments. So how does it
> become NULL? And is every caller of have_git_dir() at risk of
> segfaulting?
>
> Ah, I see.
Hello,
On Wed, Jul 31, 2019 at 7:21 PM Jonathan Nieder wrote:
>
> Jeff King wrote:
>
> > I think part of what my annoyance is responding to (and your willingness
> > to just squelch this for everybody) is that switching this particular
> > default isn't really that big a deal, that it requires an
python os.remove() throws exceptions on Windows platform when attempting to
remove file while still open.
Add local allocateTempFileName() to clarify that only the name is being
allocated by NamedTemporaryFile(); file and handle are closed (but not
deleted) when leave scope. Subsequent file deleti
Jeff King wrote:
> I think part of what my annoyance is responding to (and your willingness
> to just squelch this for everybody) is that switching this particular
> default isn't really that big a deal, that it requires annoying people
> on every single "git log" invocation. Perhaps we would be b
On Wed, Jul 31, 2019 at 02:43:10PM +0200, Johannes Schindelin wrote:
> And a corresponding Git for Windows v2.23.0-rc0 can be found here:
>
> https://github.com/git-for-windows/git/releases/tag/v2.23.0-rc0.windows.1
>
> Please test!
>
> One (slightly annoying) issue I found already is that a `g
On Thu, Aug 01, 2019 at 12:13:19AM +0200, Johannes Schindelin wrote:
> > This gets tricky, because some commands are intentionally avoiding the
> > normal lookup procedure (e.g., clone or init, and probably things like
> > upload-pack that want to enter another repo). So I think it is OK as
> > lo
Jeff King writes:
> 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-p
Hi Peff,
On Wed, 31 Jul 2019, Jeff King wrote:
> On Wed, Jul 31, 2019 at 01:06:42PM -0700, Johannes Schindelin via
> GitGitGadget wrote:
>
> > Technically, there is a way to solve this properly: teach the refs
> > machinery to initialize the ref_store from a given gitdir/commondir pair
> > (whic
On Wed, Jul 31, 2019 at 01:06:42PM -0700, Johannes Schindelin via GitGitGadget
wrote:
> Since 07b2c0eacac (config: learn the "onbranch:" includeIf condition,
> 2019-06-05), there is a potential catch-22 in the early config path: if
> the `include.onbranch:` feature is used, Git assumes that the G
2019.07.31 10:09 Andrey
>31.07.2019, 09:53, "Philip McGraw" :
>>> 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 handl
"Johannes Schindelin via GitGitGadget"
writes:
> Let's work around this, simply by ignoring the `includeif.onbranch:`
> setting when parsing the config when the ref store has not been
> initialized (yet).
Interesting chicken-and-egg problem.
> Technically, there is a way to solve this properly:
[breaking the thread since we're way off the original topic, and this
subject might get more interesting attention]
On Wed, Jul 31, 2019 at 10:17:01AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > And here it is for reference with the matching change in test-oidmap,
> > and the adjust
Jeff King writes:
> ... But in the specific case you're discussing, it seems like
> using "git update-index" might already solve your problem. It's the
> intended plumbing for scripted index updates, and it already supports
> receiving paths from stdin.
Sounds good.
On Wed, Jul 31, 2019 at 01:26:12PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > @@ -3313,8 +3319,13 @@ int cmd_pack_objects(int argc, const char **argv,
> > const char *prefix)
> > N_("do not hide commits by grafts"), 0),
> > OPT_BOOL(0, "use-bitmap
Jeff King writes:
> @@ -3313,8 +3319,13 @@ int cmd_pack_objects(int argc, const char **argv,
> const char *prefix)
> N_("do not hide commits by grafts"), 0),
> OPT_BOOL(0, "use-bitmap-index", &use_bitmap_index,
>N_("use a bitmap ind
From: Johannes Schindelin
Since 07b2c0eacac (config: learn the "onbranch:" includeIf condition,
2019-06-05), there is a potential catch-22 in the early config path: if
the `include.onbranch:` feature is used, Git assumes that the Git
directory has been initialized already. However, in the early c
I actually stumbled over this while rebasing the VFS for Git patches, in
relation with the pre-command hook that we still support there (we're slowly
migrating toward Trace2, of course).
Once I figured out what the problem was, I hunted for a way to trigger this
bug in plain Git, and git help -a i
This patch series contains a few column alignment and whitespace fixes for
perf target format. This should make it a little easier to read.
Jeff Hostetler (3):
trace2: cleanup column alignment in perf target format
trace2: trim whitespace in start message in perf target format
trace2: trim w
From: Jeff Hostetler
Trim trailing whitespace in "region_enter" and "region_leave"
messages in perf target format.
Signed-off-by: Jeff Hostetler
---
trace2/tr2_tgt_perf.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/trace2/tr2_tgt_perf.c b/trace2/tr2_tgt_perf.c
index ed4e708f28..3c7ff
From: Jeff Hostetler
Truncate/elide very long "filename:linenumber" field.
Truncate region and data "category" field if necessary.
Adjust overall column widths.
Signed-off-by: Jeff Hostetler
---
trace2/tr2_tgt_perf.c | 39 +--
1 file changed, 29 insertions(+
From: Jeff Hostetler
Trim leading/trailing whitespace from the command line
printed in the "start" message in the perf target format.
We use `sq_quote_argv_pretty()` to format the message
and it adds a leading space to the output. Trim that.
Signed-off-by: Jeff Hostetler
---
trace2/tr2_tgt_p
I actually stumbled over this while rebasing the VFS for Git patches, in
relation with the pre-command hook that we still support there (we're slowly
migrating toward Trace2, of course).
Once I figured out what the problem was, I hunted for a way to trigger this
bug in plain Git, and git help -a i
From: Johannes Schindelin
Since 07b2c0eacac (config: learn the "onbranch:" includeIf condition,
2019-06-05), there is a potential catch-22 in the early config path: if
the `include.onbranch:` feature is used, Git assumes that the Git
directory has been initialized already. However, in the early c
Hi,
On Mon, 29 Jul 2019, Pratyush Yadav wrote:
> On 29/07/19 7:58 AM, Mark Levedahl wrote:
> > On 7/28/19 6:49 PM, brian m. carlson wrote:> On 2019-07-28 at
> > 22:10:29, Pratyush Yadav wrote:
> > > > The function is not documented, and I only started spelunking
> > > > the code a couple days bac
"Slavica Djukic via GitGitGadget" writes:
> The idea: for each item that we add, we generate prefixes starting with
> the first letter, then the first two letters, then three, etc, until we
> find a prefix that is unique (or until the prefix length would be
> longer than we want). If we encounter
From: Sun Chao <16657101...@163.com>
When a packed ref is deleted, the whole packed-refs file is
rewrite and omit the ref that no longer exists. However if
another gc command is running and call `pack-refs --all`
simultaneously, there is a chance that a ref just updated
will lost the newly commits
From: Sun Chao <16657101...@163.com>
On Tue, 30 Jul 2019 02:36:35 -0400, Jeff King wrote:
> You can do this step without the fetch, which makes it hit the race more
> quickly. :) Try this:
>
> # prime it with a single commit
> git commit --allow-empty -m foo
> while true; do
> us=$(git
On 2019.07.30 09:13, Martin Ågren wrote:
> 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
"Johannes Schindelin via GitGitGadget"
writes:
> The Perl script `git-add--interactive.perl` mixed the purposes of the
> "list" and the "and choose" part into the same function. In the C
> version, we will keep them separate instead, calling the `list()`
> function from the `list_and_choose()` fu
"Daniel Ferreira via GitGitGadget" writes:
> +struct item {
> + const char *name;
> +};
> +
> +struct list_options {
> + const char *header;
> + void (*print_item)(int i, struct item *item, void *print_item_data);
> + void *print_item_data;
> +};
> +
> +struct adddel {
> + uin
"Daniel Ferreira via GitGitGadget" writes:
> @@ -6273,12 +6257,7 @@ void diff_flush(struct diff_options *options)
> dirstat_by_line) {
> struct diffstat_t diffstat;
>
> - memset(&diffstat, 0, sizeof(struct diffstat_t));
> - for (i = 0; i < q->nr;
"Johannes Schindelin via GitGitGadget"
writes:
> +add.interactive.useBuiltin::
I am not sure if three-level name is a good thing to use here.
If we have end-user controllable (like branch or remote names)
unbounded number of subcommand/submode to "add", and "interactive"
is merely one of it, th
On Wed, Jul 31, 2019 at 05:45:12PM +0200, Alexandr Miloslavskiy wrote:
> In our git UI, we sometimes run into OS commandline length limit when
> trying to specify a list of pathspecs. For example, this happens when
> user selects a large set of files and wants to commit them. As a
> workaround, we
Jeff King writes:
> And here it is for reference with the matching change in test-oidmap,
> and the adjustments necessary for the test scripts (from master, not
> from my earlier patch). I think I prefer the simpler "just sort it all"
> version I posted with the commit message.
Yeah, let's go wi
Alexandr Miloslavskiy writes:
> In our git UI, we sometimes run into OS commandline length limit when
> trying to specify a list of pathspecs. For example, this happens when
> user selects a large set of files and wants to commit them. As a
> workaround, we split files and issue multiple git comm
Jeff King writes:
> So regardless of the endian thing above, it probably does make sense for
> any hashmap iteration output to be sorted before comparing. That goes
> for t0011, too; it doesn't have this endian thing, but it looks to be
> relying on hash order that could change if we swapped out
Johannes Schindelin writes:
> For the record, I read
> https://public-inbox.org/git/xmqqh8flkgs2@gitster-ct.c.googlers.com/
> as encouraging a slightly more powerful argument in favor. Junio seemed
> to hope that PCRE2's own `pcre2grep` would behave that way, and that
> would give us plenty r
Jeff King writes:
> 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 a
Hello,
Hello,
This is a follow-up for previous discussion [1].
In our git UI, we sometimes run into OS commandline length limit when
trying to specify a list of pathspecs. For example, this happens when
user selects a large set of files and wants to commit them. As a
workaround, we split files
Christian Couder writes:
> 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 (recur
Johannes Schindelin writes:
> On Tue, 30 Jul 2019, Junio C Hamano wrote:
>
>> "Derrick Stolee via GitGitGadget" writes:
>>
>> > +#define UPDATE_DEFAULT(s,v) do { if (s == -1) { s = v; } } while(0)
>>
>> [...]
>> 3. When we learn to set default values for variables that are not
>> boolean in
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
From: Johannes Schindelin
It still does the very same thing as before, but expresses it in a much
more succinct (and still quite readable) manner.
Signed-off-by: Johannes Schindelin
---
t/t3427-rebase-subtree.sh | 36 +++-
1 file changed, 15 insertions(+), 21 de
From: Johannes Schindelin
Apart from the `setup` test case, `t3427-rebase-subtree.sh` is made up
exclusively of demonstrations of breakages. The tricky thing about such
demonstrations is that they are often buggy themselves.
In this instance, somewhere over the course of the six iterations
of th
From: Johannes Schindelin
Since 68aa495b590 (rebase: implement --merge via the interactive
machinery, 2018-12-11), the job of the old `--merge` backend is now
performed by the `--interactive` backend, too.
One consequence is that empty commits are no longer rebased by default.
Meaning that the
From: Johannes Schindelin
When rebasing a complete commit history onto a given commit, it is
pretty obvious that the root commits should be rebased on top of said
given commit.
To test this, let's kill two birds with one stone and add a test case to
t3427-rebase-subtree.sh that not only demonstr
From: Johannes Schindelin
We already support merge strategies in the sequencer, but only for
`pick` commands.
With this commit, we now also support them in `merge` commands. The
approach is simple: if any merge strategy option is specified, or if any
merge strategy other than `recursive` is spec
From: Johannes Schindelin
The test case that concerns `git rebase -Xsubtree` (with the
default rebase backend, not with `--preserve-merges`) starts out with a
pre-rebase commit history that begins with a commit that introduces
three files: master1.t, master2.t and master3.t.
This commit was gene
From: Johannes Schindelin
The format of the todo list is quite a bit different in the
`--rebase-merges` mode; Let's prepare the fake editor to handle those
todo lists properly, too.
The original idea was that we keep the original command unless
overridden, and because the original todo lists onl
From: Johannes Schindelin
Previously, this test script performed essentially three rebases and
verified breakages by testing the post-rebase commits' messages.
To do so, the rebases were performed multiple times, though, once per
commit message to test. This wastes electricity (and CO2) and time
From: Johannes Schindelin
The step to prepare a pre-rebase commit history is _identical_ in _all_
of the test cases (except of course the `setup` case). It should
therefore clearly a part of the `setup` test case instead.
As the `git filter-branch` command is quite costly on platforms where
Unix
From: Johannes Schindelin
Since 21853626ea (built-in rebase: call `git am` directly, 2019-01-18),
the built-in rebase already uses the built-in `git am` directly.
Now that d03ebd411c (rebase: remove the rebase.useBuiltin setting,
2019-03-18) even removed the scripted rebase, there is no longer a
From: Johannes Schindelin
The only remaining scripted part of `git rebase` is the
`--preserve-merges` backend. Meaning: there is little reason to keep the
"library of common rebase functions" as a separate file.
While moving the functions to `git-rebase--preserve-merges.sh`, we also
drop the `mo
From: Johannes Schindelin
This went away in 0609b741a4 (rebase -i: combine rebase--interactive.c
with rebase.c, 2019-04-17).
Signed-off-by: Johannes Schindelin
Signed-off-by: Junio C Hamano
---
.gitignore | 1 -
1 file changed, 1 deletion(-)
diff --git a/.gitignore b/.gitignore
index 875f3fc
From: Johannes Schindelin
Update a code comment that referred to those files as if they were still
there.
Signed-off-by: Johannes Schindelin
Signed-off-by: Junio C Hamano
---
sequencer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sequencer.c b/sequencer.c
index f88a97
From: Johannes Schindelin
The flow of this test script is outright confusing, and to start the
endeavor to address that, let's describe what this test is all about,
and how it tries to do it.
Signed-off-by: Johannes Schindelin
---
t/t3427-rebase-subtree.sh | 28
1
From: Johannes Schindelin
There is a test case in this script that verifies that `git rebase
--preserve-merges` works all right with non-default merge strategies or
non-default merge strategy options.
Now that `git rebase --rebase-merges` learned about merge strategies,
let's copy-edit this test
From: Johannes Schindelin
One test case's title mentioned the then-current implementation detail
that the `--am` backend was implemented in `git-rebase--am.sh`.
This is no longer the case, so let's update the title to reflect the
current reality.
Signed-off-by: Johannes Schindelin
Signed-off-b
This is the most notable shortcoming that --rebase-merges has, still,
relative to --preserve-merges' capabilities: it does not support passing
custom merge strategies or custom merge strategy options.
Let's fix this.
While working on this patch series, of course I tried to copy-edit the test
case
On Tue, Jul 30 2019, Derrick Stolee via GitGitGadget wrote:
> +feature.*::
> + The config settings that start with `feature.` modify the defaults of
> + a group of other config settings. These groups are created by the Git
> + developer community as recommended defaults and are subje
On Wed, Jul 31 2019, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 29 Jul 2019, Carlo Marcelo Arenas Belón wrote:
>
>> $ git grep 'foo bar'
>> fatal: Couldn't JIT the PCRE2 pattern 'foo bar', got '-48'
>
> My immediate reaction to this error message was: That's not helpful.
> What is `-48` su
31.07.2019, 09:53, "Philip McGraw" :
>> 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. Appar
> 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 o
Hi Junio,
On Tue, 30 Jul 2019, Junio C Hamano wrote:
> "Derrick Stolee via GitGitGadget" writes:
>
> > +#define UPDATE_DEFAULT(s,v) do { if (s == -1) { s = v; } } while(0)
>
> [...]
> 3. When we learn to set default values for variables that are not
> boolean in the future, we will regret t
Hi Ulrich,
On Tue, 30 Jul 2019, Ulrich Windl wrote:
> >>> Johannes Schindelin schrieb am
> >>> 25.07.2019 um 13:58 in Nachricht
> >>> :
> >
> > On Thu, 25 Jul 2019, Ulrich Windl wrote:
> >
> >> >>> Johannes Schindelin schrieb am
> >> >>> 25.07.2019 um 12:07 in Nachricht
> >> >>> :
> >> >
> >> >
Hi,
On Mon, 29 Jul 2019, Junio C Hamano wrote:
> An early preview release Git v2.23.0-rc0 is now available for
> testing at the usual places. It is comprised of 420 non-merge
> commits since v2.22.0, contributed by 62 people, 23 of which are
> new faces.
>
> The tarballs are found at:
>
> ht
Hi Carlo,
On Mon, 29 Jul 2019, Carlo Arenas wrote:
> 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
Hi,
On Mon, 29 Jul 2019, Carlo Marcelo Arenas Belón wrote:
> $ git grep 'foo bar'
> fatal: Couldn't JIT the PCRE2 pattern 'foo bar', got '-48'
My immediate reaction to this error message was: That's not helpful.
What is `-48` supposed to mean? Why do we even think it sensible to
throw such a
Hi,
On Sun, 28 Jul 2019, Carlo Marcelo Arenas Belón wrote:
> PCRE1 allowed for a compile time flag to disable JIT, but PCRE2 never
> had one, forcing the use of JIT if -P was requested.
>
> After ed0479ce3d (Merge branch 'ab/no-kwset' into next, 2019-07-15)
> the PCRE2 engine will be used more br
Hi brian,
On Fri, 26 Jul 2019, brian m. carlson wrote:
> On 2019-07-26 at 14:01:03, Johannes Schindelin wrote:
> > Actually, the part that uses it is not shown in the patch (one of the
> > many, many reasons why I try to discourage patch review and encourage
> > code review instead). The relevant
Hi Gábor,
On Fri, 26 Jul 2019, SZEDER Gábor wrote:
> On Fri, Jul 26, 2019 at 02:12:39PM +0200, Johannes Schindelin wrote:
>
> > Besides, I have to admit that I am quite disheartened to see these lines
> > in the log:
> >
> > -- snip --
> > 2019/07/26 11:39:28 Validated items: 0
> > 2019/07/26 11:
On 7/30/2019 5:40 PM, SZEDER Gábor wrote:
> 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, bec
On Wed, Jul 31 2019, Jeff King wrote:
> 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 st
My name is Mr.Jack.Rufon; I got your address in Burkina Faso chamber of
commerce through details. I need your urgent assistance in Transferring the sum
of (22.5, 000,000) Million Dollars fund which Belongs to our deceased customer
who died in A plane crash, since the Death of this our custome
Hi,
John Paul Adrian Glaubitz wrote:
> 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.o
87 matches
Mail list logo
