On Mon, Aug 5, 2019 at 2:53 PM Junio C Hamano wrote:
>
> Carlo Arenas writes:
>
> > LGTM except from the suggestion below that might make the code more
> > "standard"
> > and probably be a good base for a similar PCRE1 fix
> >>
> >> +static pcre2_general_context *get_pcre2_context(void)
> >> +{
On Tue, Aug 6, 2019 at 5:35 AM Junio C Hamano wrote:
>
> Emily Shaffer writes:
>
> > In backchannels recently there has been some discussion about the idea
> > of a Git-project-blessed blog written by Git contributors, generally
> > covering usability tips or overviews of the internals of Git whi
On Tue, 6 Aug 2019 at 11:51, Emily Shaffer wrote:
> Are folks interested in writing and reviewing this kind of content?
The idea sounds great, and I would be happy to review content - even
if it's only for readability and spelling!
In terms of collaborating, I've found the processes over at Git
On Mon, Aug 05, 2019 at 07:16:18PM -0700, Jonathan Nieder wrote:
> Lukas Gross wrote:
>
> > I had intended to stage commits but forgot to do so. Git responded
> > with a normal commit creation message, so I pushed to the remote to
> > begin a CI build. When the build failed for the same reason, I
Junio C Hamano writes:
> Jonathan Nieder writes:
>
Some non-judgemental descriptive output like
$ git commit --amend --no-edit
No changes.
$
would address this case, without bothering people who are doing it
intentionally. So I think there's room
Emily Shaffer writes:
> In backchannels recently there has been some discussion about the idea
> of a Git-project-blessed blog written by Git contributors, generally
> covering usability tips or overviews of the internals of Git which the
> general public tend to find confusing.
> ...
> The idea
Jonathan Nieder writes:
>>> Some non-judgemental descriptive output like
>>>
>>> $ git commit --amend --no-edit
>>> No changes.
>>> $
>>>
>>> would address this case, without bothering people who are doing it
>>> intentionally. So I think there's room for a simple improvement here.
>
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Lukas Gross wrote:
>>> I had intended to stage commits but forgot to do so. Git responded
>>> with a normal commit creation message, so I pushed to the remote to
>>> begin a CI build. When the build failed for the same reason, I
>>> realized
[...
Hi,
Here's my report from last week:
https://matheustavares.gitlab.io/posts/week-11-wip-grep-protecting-textconv-and-submodules
I'm working to protect the operations I left behind on the first
version of the patchset[1]. And for that, I used a lot of the code Duy
provided[2] me as an example in th
Jonathan Nieder writes:
> Lukas Gross wrote:
>
>> I had intended to stage commits but forgot to do so. Git responded
>> with a normal commit creation message, so I pushed to the remote to
>> begin a CI build. When the build failed for the same reason, I
>> realized I had forgotten to stage the ch
Lukas Gross wrote:
> I had intended to stage commits but forgot to do so. Git responded
> with a normal commit creation message, so I pushed to the remote to
> begin a CI build. When the build failed for the same reason, I
> realized I had forgotten to stage the changes. An additional line in
> th
(administrivia: please don't top-post)
Lukas Gross wrote:
> I had intended to stage commits but forgot to do so. Git responded
> with a normal commit creation message, so I pushed to the remote to
> begin a CI build. When the build failed for the same reason, I
> realized I had forgotten to stage
Hi all,
In backchannels recently there has been some discussion about the idea
of a Git-project-blessed blog written by Git contributors, generally
covering usability tips or overviews of the internals of Git which the
general public tend to find confusing.
Ideally, we could use a channel like th
Хорошего дня
Мы являемся зарегистрированной Кредитной Инвестиционной Компанией в
Англии, Великобритания, мы
также зарегистрирован в турецко-британской торговой палате и
Промышленность (TBCCI) мы работаем в обеих странах.
Мы ищем бенефициаров, которые получают средства для расширения / перемещения
Hi Jonathan,
I had intended to stage commits but forgot to do so. Git responded
with a normal commit creation message, so I pushed to the remote to
begin a CI build. When the build failed for the same reason, I
realized I had forgotten to stage the changes. An additional line in
the response to th
Hi,
Lukas Gross wrote:
> I have occasionally used git commit --amend without staging any
> changes or modifying the commit message (--no-edit). Since this is
> often done unintentionally, could amend warn when it is being used in
> this way?
Can you say more about the context? What were you try
Hi,
I have occasionally used git commit --amend without staging any
changes or modifying the commit message (--no-edit). Since this is
often done unintentionally, could amend warn when it is being used in
this way?
Thanks!
t7503 did not verify that the expected hooks actually ran during
testing. Fix that by making the hook scripts write their $0 into a file
so that we can compare actual execution vs. expected execution.
While we're at it, do some test style cleanups, such as using
write_script() and doing setup insi
From: Michael J Gruber
f8b863598c ("builtin/merge: honor commit-msg hook for merges", 2017-09-07)
introduced the no-verify flag to merge for bypassing the commit-msg
hook, though in a different way from the implementation in commit.c.
Change the implementation in merge.c to be the same as in com
From: Michael J Gruber
git-merge does not honor the pre-commit hook when doing automatic merge
commits, and for compatibility reasons this is going to stay.
Introduce a pre-merge-commit hook which is called for an automatic merge
commit just like pre-commit is called for a non-automatic merge co
This series adds a new pre-merge-commit hook, similar in usage to
pre-commit. It also improves hook testing in t7503, by verifying that
the correct hooks are run or bypassed as expected.
The original series was done by Michael J Gruber . I have
addressed the outstanding review comments, and noted
From: Michael J Gruber
Analogous to commit, introduce a '--no-verify' option which bypasses the
pre-merge-commit hook. The shorthand '-n' is taken by '--no-stat'
already.
[js: * reworded commit message to reflect current state of --no-stat flag
and new hook name
* fixed flag document
Ever since commit 8c8e5bd6eb33 ("merge-recursive: switch directory
rename detection default", 2019-04-05), the default handling with
directory rename detection was to report a conflict and leave unstaged
entries in the index. However, when creating a virtual merge base in
the recursive case, we ab
"lufia via GitGitGadget" writes:
> From: lufia
>
> Plan 9 don't have expr(1).
>
> Signed-off-by: lufia
> ---
> GIT-VERSION-GEN | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN
> index a0766f64ed..754d4486f5 100755
> --- a/GIT-VERSION-GE
Carlo Arenas writes:
> LGTM except from the suggestion below that might make the code more "standard"
> and probably be a good base for a similar PCRE1 fix
>>
>> +static pcre2_general_context *get_pcre2_context(void)
>> +{
>> + static pcre2_general_context *context;
>> +
>> + if (!con
Carlo Marcelo Arenas Belón writes:
> 5b594f457a (Threaded grep, 2010-01-25) added a hardcoded number of
> threads(8) to use in grep and 89f09dd34e (grep: add --threads=
> option and grep.threads configuration, 2015-12-15) made it configurable
> through a knob as a workaround for systems where th
On Mon, Aug 05, 2019 at 11:49:46AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> >>OPT_STRING('s', "source", &opts.from_treeish, "",
> >> - N_("where the checkout from")),
> >> + N_("where the checkout is from")),
> >
> > I think your or
The verbose output of every test looks something like this:
expecting success:
echo content >file &&
git add file &&
git commit -m "add file"
[master (root-commit) d1fbfbd] add file
Author: A U Thor
1 file changed, 1 insertion(+)
create mode 100644 file
Include the test script number, test number, and the test name at the
start of the verbose output of each test, to help navigating the
tests' logs.
Changes since v1:
- Include not only the test name, but the test script number and
test number as well.
- An additional small adjustment was
Our test scripts are named something like 't1234-command.sh', but the
script names used in 't-basic.sh' don't follow this naming
convention. Normally this doesn't matter, because the test scripts
themselves don't care how they are called. However, the next patch
will start to include the test
Carlo Arenas writes:
> * code is suspiciously similar to one[2] that was rejected, but
> hopefully commit message is better
> ...
> [2] https://public-inbox.org/git/20181209230024.43444-3-care...@gmail.com/
I do not recall ever rejecting that one.
It did not come with a good proposed log messag
William Chargin writes:
> Signed-off-by: William Chargin
> ---
> Assuming this is a typo, because I can't parse the sentence.
Looks good. Thanks.
>
> Documentation/git-restore.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-restore.txt b/Documen
Carlo Arenas writes:
> Thanks for fixing the conflicts in pu as well; apologize if I could
> had made it easier by doings things differently
With many topics in flight, conflicts between topics happen all the
time. Thanks for checking to catch a mismerge.
Hi Carlo,
On Mon, 5 Aug 2019, Carlo Arenas wrote:
> And forgot to mention that technically these are not UTF-8 tables but
> single byte tables like for example the ones used with en_US.ISO8859-1
Thank you for pointing that out, I completely missed that.
Junio, do you want me to re-send, or can
Hi Carlo,
On Mon, 5 Aug 2019, Carlo Arenas wrote:
> On Mon, Aug 5, 2019 at 4:51 AM Johannes Schindelin via GitGitGadget
> wrote:
> >
> > Since 7d3bf769994 (grep: avoid leak of chartables in PCRE2, 2019-08-01),
> > we try to release the UTF-8 tables obtained via `pcre2_maketables()`. To
> > do th
Jeff King writes:
>> OPT_STRING('s', "source", &opts.from_treeish, "",
>> - N_("where the checkout from")),
>> + N_("where the checkout is from")),
>
> I think your original "where to checkout from" is better.
Would we even want to do s/wh
Johannes Schindelin writes:
>> Yup. I think they are now in good shape to be among the first to
>> graduate post release. Building the warning facility necessary to
>> start dropping the $GIT_DIR/branches/ support would be too late for
>> this cycle, but now this topic is independent from that,
On 2019.08.05 11:34, Jeff Hostetler wrote:
>
>
> On 8/2/2019 6:02 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.
> >
> > This patch adds a config option
On 2019.08.05 20:01, SZEDER Gábor wrote:
> On Fri, Aug 02, 2019 at 03:02:35PM -0700, Josh Steadmon wrote:
> > +test_expect_success "don't overload target directory" '
> > + mkdir trace_target_dir &&
> > + test_when_finished "rm -r trace_target_dir" &&
> > + (
> > + GIT_TRACE2_MAX_FI
On Fri, Aug 02, 2019 at 03:02:35PM -0700, Josh Steadmon wrote:
> +test_expect_success "don't overload target directory" '
> + mkdir trace_target_dir &&
> + test_when_finished "rm -r trace_target_dir" &&
> + (
> + GIT_TRACE2_MAX_FILES=5 &&
> + export GIT_TRACE2_MA
On Mon, Aug 05, 2019 at 09:57:19AM -0400, Derrick Stolee wrote:
> On 8/5/2019 4:02 AM, SZEDER Gábor wrote:
> > While 'git commit-graph write --stdin-commits' expects commit object
> > ids as input, it accepts and silently skips over any invalid commit
> > object ids, and still exits with success:
>
Jeff King writes:
> On Sat, Aug 03, 2019 at 07:48:20AM -0700, Junio C Hamano wrote:
>
>> > Then I noticed a "can not" and updated that and other occurrences in
>> > Documentation to cannot. The glossary sentence with "can not" was
>> > "Consequently, an object can not be changed." To me, that rea
I come, hat in hand, with a bug-fix for a bug that I wrote. I just happened
to discover this issue while playing around with turning the commit-graph on
by default and stumbled into this warning.
Please see the commit message for full details, but putting octopus merges
in a tip commit-graph file
From: Derrick Stolee
In 1771be90 "commit-graph: merge commit-graph chains" (2019-06-18),
the method sort_and_scan_merged_commits() was added to merge the
commit lists of two commit-graph files in the incremental format.
Unfortunately, there was an off-by-one error in that method around
incrementi
And forgot to mention that technically these are not UTF-8 tables but
single byte tables like for example the ones used with en_US.ISO8859-1
Carlo
On Mon, Aug 5, 2019 at 4:51 AM Johannes Schindelin via GitGitGadget
wrote:
>
> Since 7d3bf769994 (grep: avoid leak of chartables in PCRE2, 2019-08-01),
> we try to release the UTF-8 tables obtained via `pcre2_maketables()`. To
> do that, we use the function `free()`. That is all fine and dandy as
On 8/2/2019 6:02 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.
This patch adds a config option (trace2.maxFiles) to set a maximum
number of files that trace2 wi
On 8/5/2019 4:02 AM, SZEDER Gábor wrote:
> While 'git commit-graph write --stdin-commits' expects commit object
> ids as input, it accepts and silently skips over any invalid commit
> object ids, and still exits with success:
>
> # nonsense
> $ echo not-a-commit-oid | git commit-graph write --
For a couple of days, maybe even a week, pu fails consistently, in the
Windows job where it tests t7816. The symptom is a segmentation fault.
I finally got to diagnose this, and it looked at first as if there was yet
another buffer overrun that was so small that valgrind failed to detect it
(see h
From: Johannes Schindelin
Since 7d3bf769994 (grep: avoid leak of chartables in PCRE2, 2019-08-01),
we try to release the UTF-8 tables obtained via `pcre2_maketables()`. To
do that, we use the function `free()`. That is all fine and dandy as
long as that refers to the system allocator.
However, w
Hi Gábor,
On Mon, 5 Aug 2019, SZEDER Gábor wrote:
> On Sun, Aug 04, 2019 at 09:14:46PM +0200, Johannes Schindelin wrote:
> >
> > On Sat, 3 Aug 2019, SZEDER Gábor wrote:
> >
> > > So the dummy test above would start like this:
> > >
> > > expecting success of 'commit works':
> > > echo
On Mon, Aug 05, 2019 at 10:02:37AM +0200, SZEDER Gábor wrote:
> While 'git commit-graph write --stdin-commits' expects commit object
> ids as input, it accepts and silently skips over any invalid commit
> object ids, and still exits with success:
>
> $ echo not-a-commit-oid | git commit-graph wr
On Sun, Aug 04, 2019 at 09:14:46PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 3 Aug 2019, SZEDER Gábor wrote:
>
> > So the dummy test above would start like this:
> >
> > expecting success of 'commit works':
> > echo content >file &&
> > [...]
>
> Maybe it would make sense
While 'git commit-graph write --stdin-commits' expects commit object
ids as input, it accepts and silently skips over any invalid commit
object ids, and still exits with success:
# nonsense
$ echo not-a-commit-oid | git commit-graph write --stdin-commits
$ echo $?
0
# sometimes I forgot
In 't5318-commit-graph.sh' the test 'close with correct error on bad
input' manually verifies the exit code of a 'git commit-graph write'
command.
Use 'test_expect_code' instead.
Signed-off-by: SZEDER Gábor
---
t/t5318-commit-graph.sh | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
dif
Signed-off-by: SZEDER Gábor
---
builtin/commit-graph.c | 6 +++---
builtin/gc.c | 2 +-
commit-graph.c | 11 ++-
commit-graph.h | 13 -
4 files changed, 18 insertions(+), 14 deletions(-)
diff --git a/builtin/commit-graph.c b/builtin/commit-graph.c
While 'git commit-graph write --stdin-commits' expects commit object
ids as input, it accepts and silently skips over any invalid commit
object ids, and still exits with success:
$ echo not-a-commit-oid | git commit-graph write --stdin-commits
$ echo $?
$ ls -l .git/objects/info/commit-graph
57 matches
Mail list logo
