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
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:
# nonsense
$ echo not-a-commit-oid | git commit-graph write --stdin-commits
$ echo $?
0
# sometimes I forgot
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
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
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
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
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
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 --
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 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
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
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
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
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
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:
>
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 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 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
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,
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
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
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
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.
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:
> * 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
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
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
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
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
"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
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
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
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
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!
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 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 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) мы работаем в обеих странах.
Мы ищем бенефициаров, которые получают средства для расширения / перемещения
(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
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
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
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
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
[...
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.
>
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
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
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
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 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 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)
> >> +{
57 matches
Mail list logo
