Got the CC list wrong in the first email...
Varun
On Thu, Jul 25, 2019 at 9:57 PM Varun Naik wrote:
>
> It is possible to delete a committed file from the index and then add it
> as intent-to-add. After `git checkout HEAD` or `git restore --staged`,
> the file should be identical in the index a
Hi Dscho,
On Thu, Jul 25, 2019 at 12:55 PM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Thu, 25 Jul 2019, Elijah Newren wrote:
>
> > diff --git a/merge-recursive.c b/merge-recursive.c
> > index 7f56cb0ed1..1a3c6ab7f3 100644
> > --- a/merge-recursive.c
> > +++ b/merge-recursive.c
> > [...]
> >
It is possible to delete a committed file from the index and then add it
as intent-to-add. After `git checkout HEAD` or `git restore --staged`,
the file should be identical in the index and HEAD. This patch provides
the desired behavior even when the file is empty in the index.
Signed-off-by: Varu
It is possible to delete a committed file from the index and then add it
as intent-to-add. After `git reset HEAD`, the file should be identical
in the index and HEAD. This patch provides the desired behavior even
when the file is empty in the index.
Signed-off-by: Varun Naik
---
CC Duy because yo
Hi everybody,
Pushes to forks of git.git hosted on GitHub now advertise the tips of
git.git as well as branches from your fork.
You may recall that Peff and I have sent a handful of patches to allow
repositories to customize how they gather references to advertise from
an alternate, and then to u
I think I've found some undesirable behavior with regards to the
behavior of `git gc --auto`. The tl;dr is that a warning message written
to gc.log can result in `git gc --auto` effectively disabling itself for
gc.logExpiry. The problem is easier to trigger in 2.22 as a result of
enabling bitmap in
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The seventh batch is in; I've merg
On Wed, Jul 24, 2019 at 04:06:50PM -0700, Josh Steadmon wrote:
> Changes since V2 of this series:
> * corrected commit message regarding the different schema variations
> * cleaned up the Makefile
> * added comment noting that the validator expects JSON-Lines input
> * added a --progress flag to th
Elijah Newren writes:
> On Thu, Jul 25, 2019 at 11:12 AM Junio C Hamano wrote:
>
>> > Stuff I'd most welcome review on:
>> > * Is cache-tree.c the right place for write_tree_from_memory()?
>> > [see patch 7] Should there be docs on how it differs from
>> > write_index_as_tree(), alrea
Hi Elijah,
On Thu, 25 Jul 2019, Elijah Newren wrote:
> In commit 7ca56aa07619 ("merge-recursive: add a label for ancestor",
> 2010-03-20), a label was added for the '||' line to make it have
> the more informative heading '|| merged common ancestors', with
> the statement:
>
> It woul
On Thu, Jul 25, 2019 at 1:12 PM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Thu, 25 Jul 2019, Elijah Newren wrote:
>
> > merge_options has several internal fields that should not be set or read
> > by external callers. This just complicates the API. Move them into an
> > opaque merge_option
Hi Phillip,
Le 24/07/2019 à 15:29, Phillip Wood a écrit :
> Hi Alban
>
> Thanks for working on this, it's great to see you back on the list and I
> think it would be a useful addition to rebase. Unfortunately I'm not
> sure about this implementation though (although the early bug fix
> patches ar
Hi Elijah,
On Thu, 25 Jul 2019, Elijah Newren wrote:
> merge_options has several internal fields that should not be set or read
> by external callers. This just complicates the API. Move them into an
> opaque merge_options_internal struct that is defined only in
> merge-recursive.c and keep the
On Thu, Jul 25, 2019 at 12:51 PM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Thu, 25 Jul 2019, Elijah Newren wrote:
>
> > We had a rule to enforce that the index matches head, but it was found
> > at the beginning of merge_trees() and would only trigger when
> > opt->call_depth was 0. Since
Hi Elijah,
On Thu, 25 Jul 2019, Elijah Newren wrote:
> It is not at all clear what 'mr' was supposed to stand for, at least not
> to me. Pick a clearer name for this variable.
I got curious, and it looks as if I introduced this in 3af244caa82
(Cumulative update of merge-recursive in C, 2006-07-
Hi Dscho,
On Thu, Jul 25, 2019 at 12:41 PM Johannes Schindelin
wrote:
>
> Hi Elijah,
>
> On Thu, 25 Jul 2019, Elijah Newren wrote:
>
> > ...And it was fixed again in commit
> > 160252f81626 ("git-merge-ours: make sure our index matches HEAD",
> > 2005-11-03)
> > ...and it was fixed again in c
Hi Elijah,
On Thu, 25 Jul 2019, Elijah Newren wrote:
> diff --git a/merge-recursive.c b/merge-recursive.c
> index 7f56cb0ed1..1a3c6ab7f3 100644
> --- a/merge-recursive.c
> +++ b/merge-recursive.c
> [...]
> @@ -434,11 +434,10 @@ struct tree *write_tree_from_memory(struct
> merge_options *opt)
>
>
Hi Elijah,
On Thu, 25 Jul 2019, Elijah Newren wrote:
> We had a rule to enforce that the index matches head, but it was found
> at the beginning of merge_trees() and would only trigger when
> opt->call_depth was 0. Since merge_recursive() doesn't call
> merge_trees() until after returning from r
Hi Elijah,
On Thu, 25 Jul 2019, Elijah Newren wrote:
> This is the bug that just won't die; there always seems to be another
> form of it somewhere. See the commit message of 55f39cf7551b ("merge:
> fix misleading pre-merge check documentation", 2018-06-30) for a more
> detailed explanation), bu
Hi Elijah,
On Thu, 25 Jul 2019, Elijah Newren wrote:
> * All current callers (3 of them?) of merge_recursive() always pass
> it a specially created reversed-list for the merge_bases. Some
> history spelunking provides no details on any of these about why;
> it appears that the 2nd
On Thu, Jul 25, 2019 at 11:12 AM Junio C Hamano wrote:
> > Stuff I'd most welcome review on:
> > * Is cache-tree.c the right place for write_tree_from_memory()?
> > [see patch 7] Should there be docs on how it differs from
> > write_index_as_tree(), already found in cache-tree? What d
Hi Junio,
On Thu, 25 Jul 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > I had prepared these patches even before v2.22.0, but deemed them not
> > critical enough to push into that release.
>
> Thanks. Both of these look quite sensible. Will queue and
> fas
Hi Junio,
On Thu, 25 Jul 2019, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > "Johannes Schindelin via GitGitGadget"
> > writes:
> >
> >> From: Johannes Schindelin
> >>
> >> We started marking all of those test cases that require `git rebase -p`
> >> to work in the recent past, to allow
Hi Junio,
On Thu, 25 Jul 2019, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> >> OK, in short, barfing and stopping is a problem, but that flag is
> >> not the right knob to tweak. And the right knob ...
> >>
> >> > 1) We're oversupplying PCRE2_UTF now, and one such case is what's bei
Elijah Newren writes:
> Before writing a replacement merge strategy for recursive, I decided
> to first cleanup the merge API -- streamlining merge-recursive.h and
> making it more readable. It includes some fixes I noticed along the
> way, and the last two patches were some forgotten changes of
Other than cache.h which needs to appear first, and merge-recursive.h
which I want to be second so that we are more likely to notice if
merge-recursive.h has any missing includes, the rest of the list is
long and easier to look through if it's alphabetical.
Signed-off-by: Elijah Newren
---
merge
In commit 8daec1df03de ("merge-recursive: switch from (oid,mode) pairs
to a diff_filespec", 2019-04-05), an assertion on a->path && b->path
was added for code readability to document that these both needed to be
non-NULL at this point in the code. However, the subsequent lines also
read o->path, s
No substantive code changes (view this with diff --color-moved), but
a few small code cleanups:
* Move structs and an inline function only used by merge-recursive.c
into merge-recursive.c
* Re-order function declarations to be more logical
* Add or fix some explanatory comments
Signed-of
In commit 7ca56aa07619 ("merge-recursive: add a label for ancestor",
2010-03-20), a label was added for the '||' line to make it have
the more informative heading '|| merged common ancestors', with
the statement:
It would be nicer to use a more informative label. Perhaps someone
w
We provided users with the ability to state whether they wanted rename
detection, and to put a limit on how much CPU would be spent. Both of
these fields had multiple configuration parameters for setting them,
with one being a fallback and the other being an override. However,
instead of implemen
The merge_options struct had lots of fields, making it a little
imposing, but the options naturally fall into multiple different groups.
Grouping similar options and adding a comment or two makes it easier to
read, easier for new folks to figure out which options are related, and
thus easier for th
I want to implement the same outward facing API as found within
merge-recursive.h in a different merge strategy. However, that makes
names like MERGE_RECURSIVE_{NORMAL,OURS,THEIRS} look a little funny;
rename to MERGE_VARIANT_{NORMAL,OURS,THEIRS}.
Signed-off-by: Elijah Newren
---
merge-recursiv
Returning before freeing the allocated buffer is suboptimal; as with
elsewhere in the same function, make sure buf gets free'd.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
ind
In commit 259ccb6cc324 ("merge-recursive: rename merge_options argument
from 'o' to 'opt'", 2019-04-05), I renamed a bunch of function
arguments in merge-recursive.c, but forgot to make that same change to
merge-recursive.h. Make the two match.
Signed-off-by: Elijah Newren
---
merge-recursive.h
We had a rule to enforce that the index matches head, but it was found
at the beginning of merge_trees() and would only trigger when
opt->call_depth was 0. Since merge_recursive() doesn't call
merge_trees() until after returning from recursing, this meant that the
check wasn't triggered by merge_r
No substantive code change, just add some line breaks to fix lines that
have grown in length due to various refactorings. Most remaining lines
of excessive length in merge-recursive include error messages and it's
not clear that splitting those improves things.
Signed-off-by: Elijah Newren
---
merge_trees(), merge_recursive(), and merge_recursive_generic() in
their function headers used four different names for the merge base or
list of merge bases they were passed:
* 'common'
* 'ancestors'
* 'ca'
* 'base_list'
They were able to refer to it four different ways instead of only thr
write_tree_from_memory() is more of a cache-tree thing than a
merge-recursive thing (especially since it is called from checkout.c in
a context before doing anything with merging), but in particular there
is no need for it to take a merge_options struct when it only really
needs a repository struct
merge_options has several internal fields that should not be set or read
by external callers. This just complicates the API. Move them into an
opaque merge_options_internal struct that is defined only in
merge-recursive.c and keep these out of merge-recursive.h.
Signed-off-by: Elijah Newren
---
No code changes, just moving the function to what seems like a more
logical place.
Signed-off-by: Elijah Newren
---
cache-tree.c | 30 ++
cache-tree.h | 2 ++
merge-recursive.c | 30 --
merge-recursive.h | 1 -
4 files changed,
Alternatively, you can view this as "make the merge functions behave
more similarly." merge-recursive has three different entry points:
merge_trees(), merge_recursive(), and merge_recursive_generic(). Two of
these would call diff_warn_rename_limit(), but merge_trees() didn't.
This lead to callers
Commit d7cf3a96e9a0 ("merge-recursive.c: remove implicit dependency on
the_repository", 2019-01-12) and follow-ups like commit 34e7771bc644
("Use the right 'struct repository' instead of the_repository",
2019-06-27), removed most implicit uses of the_repository. Convert
calls to get_commit_tree()
This is the bug that just won't die; there always seems to be another
form of it somewhere. See the commit message of 55f39cf7551b ("merge:
fix misleading pre-merge check documentation", 2018-06-30) for a more
detailed explanation), but in short:
builtin/merge.c contains this important requirem
It is not at all clear what 'mr' was supposed to stand for, at least not
to me. Pick a clearer name for this variable.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 0a9054
Before writing a replacement merge strategy for recursive, I decided
to first cleanup the merge API -- streamlining merge-recursive.h and
making it more readable. It includes some fixes I noticed along the
way, and the last two patches were some forgotten changes of mine I
rediscovered that had mi
Hi Junio,
There's a repo for each language, with the same file structure.
For example, English version (upstream):
https://github.com/javascript-tutorial/en.javascript.info/blob/master/1-js/01-getting-started/1-intro/article.md
Japanese:
https://github.com/javascript-tutorial/ja.javascript.info/
"Johannes Schindelin via GitGitGadget"
writes:
> ... As a consolation to myself, this work was actually worth it, surprising as
> that may look. Not only is t3427 now really easy to understand, adding that
> test case for --rebase-merges -Xsubtree tickled the sequencer enough to
> reveal a long-s
Josh Steadmon writes:
> diff --git a/t/trace_schema_validator/README b/t/trace_schema_validator/README
> new file mode 100644
> index 00..45f0e6f0c4
> --- /dev/null
> +++ b/t/trace_schema_validator/README
> @@ -0,0 +1,23 @@
> +These JSON schemas[1] can be used to validate trace2 event obj
Junio C Hamano writes:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
>> From: Johannes Schindelin
>>
>> We started marking all of those test cases that require `git rebase -p`
>> to work in the recent past, to allow for skipping them (because the
>> `--preserve-merges` backend is already
Ilya Kantor writes:
> We're using Git to manage translations of an open-source book, and
> most of time it works well. But there's also a problem.
>
> When we pull changes from upstream (English) to translation
> (e.g. Japanese), git auto-merges them.
>
> Sometimes there conflicts, but not all th
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> We started marking all of those test cases that require `git rebase -p`
> to work in the recent past, to allow for skipping them (because the
> `--preserve-merges` backend is already deprecated and will be removed in
SZEDER Gábor writes:
>> I would appreciate any feedback on better ways to integrate the
>> validator into the CI suite.
>
> How about adding a test script dedicated to JSON schema validation,
> which runs only as many git commands as needed to cover all trace2
> events.
Sensible, but might be ha
"Johannes Schindelin via GitGitGadget"
writes:
> I had prepared these patches even before v2.22.0, but deemed them not
> critical enough to push into that release.
Thanks. Both of these look quite sensible. Will queue and
fast-track.
Hi,
I'm not completely sure if this is the best way to achieve this, but I
you could instruct a merge driver to mark all new files as unset.
Cheers!
-Santiago.
On Thu, Jul 25, 2019 at 04:42:48PM +0300, Ilya Kantor wrote:
> Hi,
>
> We're using Git to manage translations of an open-source book, a
On 25/07/19 5:04 PM, Christian Couder wrote:
Hi Pratyush,
On Wed, Jul 24, 2019 at 11:43 PM Pratyush Yadav wrote:
I have a quick little feature to add to git-gui, and I'm wondering where
should I discuss it and send patches. The git-gui repo [0] has no readme
I can see that would point me in t
Hi,
We're using Git to manage translations of an open-source book, and most of time
it works well. But there's also a problem.
When we pull changes from upstream (English) to translation (e.g. Japanese),
git auto-merges them.
Sometimes there conflicts, but not all the time.
For example, when
Johannes Schindelin writes:
>> OK, in short, barfing and stopping is a problem, but that flag is
>> not the right knob to tweak. And the right knob ...
>>
>> > 1) We're oversupplying PCRE2_UTF now, and one such case is what's being
>> > reported here. I.e. there's no reason I can think of f
I create 001.patch in dir, ceph_master
ceph_master
|--- .git
|--- src
|--- tools
|--- ...
local project directory:
storage
|---.git
|---ceph_**.*.**
|--- src
|--- tools
|--- ...
I'm trying to apply the patch, and git apply patch doesn't give me any errors.
like this
cd storage/ceph_*
Hi,
On Wed, 24 Jul 2019, Pratyush Yadav wrote:
> I have a quick little feature to add to git-gui, and I'm wondering
> where should I discuss it and send patches. The git-gui repo [0] has
> no readme I can see that would point me in the right direction.
> Googling around didn't get me anything eit
Hi Ulrich,
On Thu, 25 Jul 2019, Ulrich Windl wrote:
> >>> Johannes Schindelin schrieb am 25.07.2019 um
> 12:07
> in Nachricht :
> >
> > On Wed, 24 Jul 2019, Ulrich Windl wrote:
> >
> >> When using "git merge --no-ff --no-commit ..", the pre-created
> >> merge message always contains two empty li
Hi Pratyush,
On Wed, Jul 24, 2019 at 11:43 PM Pratyush Yadav wrote:
>
> I have a quick little feature to add to git-gui, and I'm wondering where
> should I discuss it and send patches. The git-gui repo [0] has no readme
> I can see that would point me in the right direction. Googling around
> did
On Wed, Jul 24, 2019 at 04:06:50PM -0700, Josh Steadmon wrote:
> This is a proof of concept series that formalizes the structure of trace2
> event
> output using JSON-Schema [1].
>
> It provides a validator (written in Go) that verifies the events in a given
> trace2 event output file match the s
Signed-off-by: simon gao
---
apply.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/apply.c b/apply.c
index 4992eca..47b16aa 100644
--- a/apply.c
+++ b/apply.c
@@ -2093,8 +2093,10 @@ static int use_patch(struct apply_state *state, struct
patch *p)
/* Paths outside
Signed-off-by: simon gao
---
apply.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/apply.c b/apply.c
index 4992eca..f66a6ff 100644
--- a/apply.c
+++ b/apply.c
@@ -2094,6 +2094,7 @@ static int use_patch(struct apply_state *state, struct
patch *p)
if (state->prefix && *state->prefix)
>>> Johannes Schindelin schrieb am 25.07.2019 um
12:07
in Nachricht :
> Hi Ulrich,
>
> On Wed, 24 Jul 2019, Ulrich Windl wrote:
>
>> I think I had tried bringing this to your attention before, but I think it
> was
>> without success.
>> The issue may seem purely cosmetical, while being easy to
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
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
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
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
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
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.
Signed-off-by: Johannes Schindelin
---
t/lib-rebase.sh | 8
1 file changed, 4 insertions(+), 4 deletion
From: Johannes Schindelin
To prepare for the long game, where the `--preserve-merges` backend will
be dropped eventually, we already introduced the `REBASE_P` prerequisite
to allow saving time by skipping the now-almost-pointless test cases
that verify that that backend works as expected.
Due to
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
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
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
Hi Ulrich,
On Wed, 24 Jul 2019, Ulrich Windl wrote:
> I think I had tried bringing this to your attention before, but I think it was
> without success.
> The issue may seem purely cosmetical, while being easy to fix (is my guess):
>
> When using "git merge --no-ff --no-commit ..", the pre-created
Hi,
On Wed, 24 Jul 2019, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > The PCRE2_NO_UTF_CHECK flag means "I have checked that this is a valid
> > UTF-8 string so you, PCRE, don't need to re-check it".
>
> OK, in short, barfing and stopping is a problem, but that flag is
> not the
Hi Stolee,
On Wed, 24 Jul 2019, Derrick Stolee via GitGitGadget wrote:
> Updates in V2: I'm responding to Dscho's comments early, as they were very
> valuable.
>
> * Rearranged how we are checking for the feature.* settings, so if one
>layer turns the setting on and a later layer turns it of
Hi Stolee,
On Wed, 24 Jul 2019, Derrick Stolee via GitGitGadget wrote:
> diff --git a/builtin/update-index.c b/builtin/update-index.c
> index dff2f4b837..5ced51c1ee 100644
> --- a/builtin/update-index.c
> +++ b/builtin/update-index.c
> @@ -18,6 +18,7 @@
> #include "dir.h"
> #include "split-inde
Hi Stolee,
On Wed, 24 Jul 2019, Derrick Stolee via GitGitGadget wrote:
> diff --git a/repo-settings.h b/repo-settings.h
> new file mode 100644
> index 00..89fb0159bf
> --- /dev/null
> +++ b/repo-settings.h
> @@ -0,0 +1,17 @@
> +#ifndef REPO_SETTINGS_H
> +#define REPO_SETTINGS_H
> +
> +str
Hi Emily,
On Mon, 1 Jul 2019, Emily Shaffer wrote:
> Since v2, mostly reworded comments, plus fixed the issues mentioned in
> the tutorial itself. Thanks Eric for the review.
>
> Emily Shaffer (13):
> walken: add infrastructure for revwalk demo
> walken: add usage to enable -h
> walken: add
From: Johannes Schindelin
We started marking all of those test cases that require `git rebase -p`
to work in the recent past, to allow for skipping them (because the
`--preserve-merges` backend is already deprecated and will be removed in
one of the next major versions, so it is a bit pointless t
I had forgotten those previously. Sorry.
Please note that there is another set of test cases in t3427 that desires
the REBASE_P prerequisite. However, I would like to address this as part of
https://github.com/gitgitgadget/git/pull/294 instead (because I kind of had
to pour substantial work into
Hi Beat,
On Wed, 24 Jul 2019, Beat Bolli wrote:
> On 23.07.19 21:19, Johannes Schindelin wrote:
> >
> > On Mon, 22 Jul 2019, Beat Bolli wrote:
> >
> >> When pcre2_jit_on is neither 1 nor 0, the BUG() call printed the value
> >> of pcre1_jit_on.
> >>
> >> Print the value of pcre2_jit_on instead.
>
Hi,
On Wed, 24 Jul 2019, Phillip Wood wrote:
> On 17/07/2019 15:39, Alban Gruin wrote:
>
> > To prevent mistakes when editing a branch, rebase features a knob,
> > rebase.missingCommitsCheck, to warn the user if a commit was
> > dropped. Unfortunately, this check is only effective for the
> > in
88 matches
Mail list logo
