Am 02.08.19 um 23:20 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Having cmd_log_init_finish() call load_ref_decorations() before
>> setup_revisions() would indeed solve the issue as well. But we need
>> to call the latter to check if --pretty=raw was given and avoid loading
>> decorations
gabrielreyes...@gmail.com
> On Jul 3, 1 Reiwa, at 14:50, Gabriel Camaisa Reyes
> wrote:
>
>
>
>
>
>
> gabriel...@gmail.com
I noticed a couple typos while reading through some manpages.
First was "...if it is does not..." which just contained an extraneous "is".
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 obje
From: Mark Rushakoff
"Can not" suggests one has the option to not do something, whereas
"cannot" more strongly suggests something is disallowed or impossible.
Noticed "can not", mistakenly used instead of "cannot" in git help
glossary, then ran git grep 'can not' and found many other instances.
SZEDER Gábor wrote:
> On Fri, Aug 02, 2019 at 09:59:13AM -0700, Jonathan Nieder wrote:
>> In the short term, we can run tests internally to check that Git keeps
>> following the schema. Let's not block patches 1 and 2 by this ---
>
> To my understanding patch 2 is only a proof of concept: it star
On Fri, Aug 02, 2019 at 02:20:31PM -0700, Junio C Hamano wrote:
> > This would require that higher level to parse the user format to check
> > if %d or %D is present before formatting the first item. Hmm.
>
> Yes. Don't we pre-scan what kind of formatting primitives are used
> in the end-user s
SZEDER Gábor wrote:
> On Thu, Aug 01, 2019 at 06:52:47PM -0700, Jonathan Nieder wrote:
>> Gábor, if we introduce such a parameter, do you think it would make
>> sense for us to set up a worker that passes it?
>
> That would be even worse than the current approach of the third patch,
> because the
On Fri, Aug 02, 2019 at 02:04:09PM -0700, Junio C Hamano wrote:
> > +static int run_help(struct add_i_state *s, const struct pathspec *ps,
> > + struct file_list *files, struct list_options *opts)
> [...]
>
> As we do not allow the command names to get translated, this makes
> sense
On 2019.08.02 11:45, Martin Ågren wrote:
> On Fri, 2 Aug 2019 at 00:20, Josh Steadmon wrote:
>
> > diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
> > index 82cd573776..7c4c994858 100644
> > --- a/Documentation/githooks.txt
> > +++ b/Documentation/githooks.txt
> > @@ -103,6 +
On 2019.08.02 11:56, Martin Ågren wrote:
> [Dropped cc-list the first time around. Apologies to those who receive
> this twice...]
>
> On Fri, 2 Aug 2019 at 00:20, Josh Steadmon wrote:
> >
> > This series adds a new pre-merge-commit hook, similar in usage to
> > pre-commit. It also improves hook
Hi all:
Another question that came up for me recently. Using:
git log --numstat
I am seeing multiple emails attached to a single commit as described here:
https://stackoverflow.com/questions/57333971/git-log-numstat-has-weird-data
does anyone know what that means?
-alex
--
Alexander D. Mi
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 first release candidate for 2.
A release candidate Git v2.23.0-rc1 is now available for testing
at the usual places. It is comprised of 471 non-merge commits
since v2.22.0, contributed by 63 people, 23 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following pu
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 will write to a target directory. The
following b
Move the description of trace2's target-directory behavior into the
shared trace2-target-values file so that it is included in both the
git-config and api-trace2 docs. Leave the SID discussion only in
api-trace2 since it's a technical detail.
Signed-off-by: Josh Steadmon
---
Documentation/techni
I'm sending out V2 still as an RFC because I haven't yet had time to
check that directory contention doesn't create problems with multiple
processes sharing the same target directory. I'll be on vacation for the
next couple of weeks, so I wanted to get the new config variable version
out before the
René Scharfe writes:
> Having cmd_log_init_finish() call load_ref_decorations() before
> setup_revisions() would indeed solve the issue as well. But we need
> to call the latter to check if --pretty=raw was given and avoid loading
> decorations in that case, don't we?
I was thinking about givin
Johannes Schindelin writes:
>> As I am a heavy user of git add -p myself and use a patched version for
>> weeks already (it is so nice to not suffer over one second startup until the
>> MSYS2 Perl finally shows me anything, instead it feels instantaneous), I
>> integrated these patch series into
"Johannes Schindelin via GitGitGadget"
writes:
> +static int run_help(struct add_i_state *s, const struct pathspec *ps,
> + struct file_list *files, struct list_options *opts)
> +{
> + const char *help_color = s->help_color;
> +
> + color_fprintf_ln(stdout, help_color, "st
Hi Junio
On Fri, 19 Jul 2019 15:36:15 -0700 Junio C Hamano wrote:
>
> [...]
> Hmph, are we sure that author-script is always available at this
> point so that a call to read_author_date_or_die() is safe? There
> are three callers to the run_git_commit() function and I am not sure
> if codepaths
Peníze vám darovali manželé Allen a Violet Large, pro další informace je
kontaktujte v tomto e-mailu
Kontaktujte emailail: allen.viiolet.la...@gmail.com
Am 02.08.19 um 21:14 schrieb Junio C Hamano:
> I can see how this would help, but it somehow feels a bit brittle
> to rely on where the decorations get loaded.
Right.
> I wonder if it would help to move the ability to handle decoration
> filter down from the log layer to revisions.c API layer.
>
On 8/2/19 10:17 PM, Junio C Hamano wrote:
Pratyush Yadav writes:
+Junio
I do not have a strong opinion on this one---a Meh by default means
a moderately strong preference for status-quo.
All right, the patch in its current state can't fly. So what is the
correct way to do this? I see the f
On 8/2/19 6:09 PM, Johannes Schindelin wrote:
Hi,
On Fri, 2 Aug 2019, Pratyush Yadav wrote:
On 8/1/19 1:12 AM, Johannes Schindelin wrote:
I would be _extremely_ cautious to base an argument on one
particular setup, using on particular hardware with one particular
OS and one particular reposi
Take new approach using the NamedTemporaryFile() file-like object as input
to the ZipFile() which auto-deletes after implicit close leaving with scope.
Original code produced double-open problems on Windows platform from using
already open NamedTemporaryFile() generated filename instead of object.
On Fri, Aug 02, 2019 at 09:59:13AM -0700, Jonathan Nieder wrote:
> The exhaustive approach really helps. Arguing against it kind of
> feels like saying "leak checkers are great, but why run one on the
> full test suite instead of a dedicated tool that exercises the code
> paths where you expect to
Piotr Krukowiecki writes:
> At this moment I'm not sure myself if I consider this a bug or not.
This definitely is not a bug but is a designed and intended
behaviour.
Think of running "git log" without "--full-history" that is limited
with a pathspec as a tool to ask Git to show _one_ way (pref
On Fri, Aug 2, 2019 at 4:22 PM Derrick Stolee wrote:
>
> On 8/2/2019 5:38 AM, Piotr Krukowiecki wrote:
> > Hi,
> >
> > I have merged a branch into master.
> >
> > When on master I do "git log -- some/file", it does not show commits
> > from merged branch (which I know they changed the file).
> > I
On Thu, Aug 01, 2019 at 06:52:47PM -0700, Jonathan Nieder wrote:
> What do you think of making the validation disabled by default and
> using a parameter (see "Running tests with special setups" in
> t/README) to turn it on? That way, it should be okay for it to take
> 10 minutes because this woul
René Scharfe writes:
> Am 02.08.19 um 10:47 schrieb Étienne SERVAIS:
>> Thus, when I enter
>>
>> ```
>> git log --oneline --graph --decorate=full
>> --decorate-refs-exclude='refs/tags/'
>> ```
>> The selected tags are properly excluded but once I add the
>> `simplify-by-decoration` option
>>
>>
On Fri, Aug 02, 2019 at 02:12:34PM +0200, Johannes Schindelin wrote:
> > > * js/early-config-with-onbranch (2019-07-31) 1 commit
> > > (merged to 'next' on 2019-08-01 at 26b713c824)
> > > + config: work around bug with includeif:onbranch and early config
> > >
> > > The recently added [include
On Fri, Aug 02, 2019 at 09:53:55AM -0700, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> > We'll also want to update the docs. And as Todd suggests, we should
> > cover how to disable mailmap in tests.
> >
> > Signed-off-by: Jonathan Nieder
> > ---
>
> I avoided the "don't bother initial
Hi,
Johannes Schindelin wrote:
> On Thu, 1 Aug 2019, Jonathan Nieder wrote:
>> What do you think of making the validation disabled by default and
>> using a parameter (see "Running tests with special setups" in
>> t/README) to turn it on? That way, it should be okay for it to take
>> 10 minutes
Jonathan Nieder writes:
> We'll also want to update the docs. And as Todd suggests, we should
> cover how to disable mailmap in tests.
>
> Signed-off-by: Jonathan Nieder
> ---
I avoided the "don't bother initializing use_mailmap_config to
unknown" simplification, but I guess the change is clea
Am 02.08.19 um 10:47 schrieb Étienne SERVAIS:
> Thus, when I enter
>
> ```
> git log --oneline --graph --decorate=full
> --decorate-refs-exclude='refs/tags/'
> ```
> The selected tags are properly excluded but once I add the
> `simplify-by-decoration` option
>
> ```
> git log --oneline --graph -
Pratyush Yadav writes:
> +Junio
I do not have a strong opinion on this one---a Meh by default means
a moderately strong preference for status-quo.
> All right, the patch in its current state can't fly. So what is the
> correct way to do this? I see the following options:
>
> 1. Add this as an o
Johannes Schindelin writes:
> Hi Junio,
>
> On Thu, 1 Aug 2019, Junio C Hamano wrote:
>
>> * js/visual-studio (2019-07-29) 23 commits
>> - git: avoid calling aliased builtins via their dashed form
>> - bin-wrappers: append `.exe` to target paths if necessary
>> - .gitignore: ignore Visual Stud
SZEDER Gábor writes:
>> > t: warn against adding non-httpd-specific tests after sourcing
>> > 'lib-httpd'
>>
>> That reads well.
>
> Ok. Should I resend, or will you amend? (I see that 'pu' contains the
> old subject line).
I do not think the original was too bad, either, but I'll amend;
th
It is possible to delete a committed file from the index and then add it
as intent-to-add. After `git checkout HEAD `, the file should
be identical in the index and HEAD. The command already works correctly
if the file has contents in HEAD. This patch provides the desired
behavior even when the fil
Jeff King writes:
> On Thu, Aug 01, 2019 at 01:05:12PM -0700, Junio C Hamano wrote:
>
>> [Graduated to "master"]
>> [...]
>> * jk/repack-silence-auto-bitmap-warning (2019-07-31) 3 commits
>> (merged to 'next' on 2019-07-31 at 3aa218347c)
>> + repack: simplify handling of auto-bitmaps and .keep
Carlo Marcelo Arenas Belón writes:
> 94da9193a6 ("grep: add support for PCRE v2", 2017-06-01) introduced
> a small memory leak visible with valgrind in t7813.
>
> Complete the creation of a PCRE2 specific variable that was missing from
> the original change and free the generated table just like
Varun Naik writes:
> `git restore --staged` uses the same machinery as `git checkout HEAD`,
> so there should be a similar test case for "restore" as the existing
> test case for "checkout" with deleted ita files.
>
> Helped-by: Jeff King
> Signed-off-by: Varun Naik
> ---
> This is the "restore
Hello Eugen,
sorry, everything is OK. rafasc suggested me what is the problem.
I should use --full-history
Friday, August 2, 2019, 6:39:54 PM, you wrote:
> Hello Git,
> I add and remove only blank lines at my file:
> $ git log -p t/29-cmd_l.t
> --- a/t/29-cmd_l.t
> +++ b/t/29-cmd_l.t
> @@ -
Hello Git,
I add and remove only blank lines at my file:
$ git log -p t/29-cmd_l.t
--- a/t/29-cmd_l.t
+++ b/t/29-cmd_l.t
@@ -218,7 +218,6 @@ __DATA__
@@ list
-e:0005 1;
-e:00022;
-
-e
0: use Devel::DbBatch split(/,/,q{list.conf;b 2;a 2 1;s 2;l .;q});;
1: sub t {
@@ -226,26
Am Mrs.Joy Titus from London,58 years an aging widow suffering from
long time illness. I have the sum of $17.5M Dollars For you to use the
fund for God’s work.Please if you would be able to use the funds for
the Lord’s work,reply me:(jottit...@gmail.com)
Yours in the Lord
Mrs.Joy Titus
On 19-08-01 13:24:00, Junio C Hamano wrote:
Mateusz Loskot writes:
Is there any other way, without remembering to `git merge` with `--log`?
"git config merge.log true"?
That's sweet! Thank you
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Fingerprint=C081 EA1B 4AFB 7C19 38BA
On 02.08.2019 16:47, Johannes Schindelin wrote:
> and definitely does *not* want to write a file.
In this case it can use `--paths-file -`, which means stdin.
Zilch. So I find the advice you received, let's say, interesting.
I understood that `--paths-file` is suggested to avoid possible
std
On 02.08.2019 16:48, Johannes Schindelin wrote:
How about subscribing to that PR so you get updates without requiring me
to remember to send you a manual email?
This option evaded me :) Subscribed, thanks!
Hi Alexandr,
On Fri, 2 Aug 2019, Alexandr Miloslavskiy wrote:
> On 02.08.2019 13:33, Johannes Schindelin wrote:
> > Please note that I have a patch series (currently on hold because of the
> > v2.23.0 feature freeze) to teach `git reset` an `--stdin` option:
> > https://github.com/gitgitgadget/gi
Hi Alexandr,
On Fri, 2 Aug 2019, Alexandr Miloslavskiy wrote:
> On 02.08.2019 13:33, Johannes Schindelin wrote:
> > to teach `git reset` an `--stdin` option:
>
> I think it should be changed to follow the approach decided
> here [1] - that is, use '--paths-file', and '--paths-file -'
> will mean
From: Anthony Busconi
Sent: Friday, August 02, 2019 10:03 AM
Subject: Employees What-to-do on Earnings..
Your Payroll Earning Statement for direct deposit for August 2019 is
available for viewing and HRM would like you to kindly update your
information's
On 8/2/2019 5:38 AM, Piotr Krukowiecki wrote:
> Hi,
>
> I have merged a branch into master.
>
> When on master I do "git log -- some/file", it does not show commits
> from merged branch (which I know they changed the file).
> I have to add "--full-history" to see the commits.
> When I run "git lo
Re-Cc:ing the Git mailing list.
Please make sure to keep the Git mailing list in Cc:. I get extremely
testy when I see mails asking me for personal help in private. As long
as others can learn from my answers, I am fine with helping. I stop
being fine when I feel like I am mistaken for a free-of-c
Hi,
On Fri, 2 Aug 2019, Pratyush Yadav wrote:
> On 8/1/19 1:12 AM, Johannes Schindelin wrote:
> >
> > I would be _extremely_ cautious to base an argument on one
> > particular setup, using on particular hardware with one particular
> > OS and one particular repository.
> >
>
> Agreed. That's why
Hi Peff,
On Thu, 1 Aug 2019, Jeff King wrote:
> On Thu, Aug 01, 2019 at 01:05:12PM -0700, Junio C Hamano wrote:
>
> > * js/early-config-with-onbranch (2019-07-31) 1 commit
> > (merged to 'next' on 2019-08-01 at 26b713c824)
> > + config: work around bug with includeif:onbranch and early config
Hi Junio,
On Thu, 1 Aug 2019, Junio C Hamano wrote:
> * js/visual-studio (2019-07-29) 23 commits
> - git: avoid calling aliased builtins via their dashed form
> - bin-wrappers: append `.exe` to target paths if necessary
> - .gitignore: ignore Visual Studio's temporary/generated files
> - .git
Hi Jonathan & Josh,
On Thu, 1 Aug 2019, Jonathan Nieder wrote:
> Josh Steadmon wrote:
> > On 2019.07.26 15:03, Josh Steadmon wrote:
>
> >> [ajv-cli] can validate the full 1.7M line trace output in just over a
> >> minute. Moreover, it has helpful output when validation fails. So I
> >> would be h
On 02.08.2019 13:33, Johannes Schindelin wrote:
to teach `git reset` an `--stdin` option:
I think it should be changed to follow the approach decided
here [1] - that is, use '--paths-file', and '--paths-file -'
will mean "from stdin"
[1]
https://public-inbox.org/git/a6610e94-6318-b962-5dd0-ca
On 02.08.2019 13:33, Johannes Schindelin wrote:
Please note that I have a patch series (currently on hold because of the
v2.23.0 feature freeze) to teach `git reset` an `--stdin` option:
https://github.com/gitgitgadget/git/pull/133
Perfect! Less work for me :)
Once your patch is accepted, could
@Johannes, thanks a lot for your tips!
On 02.08.2019 13:40, Johannes Schindelin wrote:
From past experience, I find that it is important to also implement the
`-z` option (which traditionally means: accept items via the command
line that are delimited by NULs).
And you might find inspiration i
Hi Alexandr,
On Thu, 1 Aug 2019, Alexandr Miloslavskiy wrote:
> On 01.08.2019 22:45, Junio C Hamano wrote:
> > That does not mean that any patch along that line will automatically
> > be accepted, of course, so the answer to "am I ready to accept"
> > question is a definite no. No, I am not read
Hi Alexandr,
On Thu, 1 Aug 2019, Alexandr Miloslavskiy wrote:
> 4) git reset
Please note that I have a patch series (currently on hold because of the
v2.23.0 feature freeze) to teach `git reset` an `--stdin` option:
https://github.com/gitgitgadget/git/pull/133
Ciao,
Johannes
On Thu, Aug 01, 2019 at 11:18:42AM -0700, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > On Thu, Aug 01, 2019 at 05:53:09PM +0200, SZEDER Gábor wrote:
> >> Subject: Re: [PATCH 3/3] tests: warn against appending non-httpd-specific
> >> tests at the end
> >
> > This subject line kind of sucks,
On Fri, 2 Aug 2019 at 00:20, Josh Steadmon wrote:
>
> 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.
It could be argued that this test is p
Signed-off-by: Martin Ågren
---
t/t7503-pre-commit-and-pre-merge-commit-hooks.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t7503-pre-commit-and-pre-merge-commit-hooks.sh
b/t/t7503-pre-commit-and-pre-merge-commit-hooks.sh
index 86a375ab3e..5cc6c98375 100755
--- a/t
Rather than creating an empty "expected_hooks" file and another empty
file "actual_hooks" (which we want to not be appended to), just verify
that "actual_hooks" isn't created. Do still clean up the "actual_hooks"
file, so that a failing test won't start affecting later tests too.
Signed-off-by: Ma
If we fail to call the hook, we won't append to "actual_hooks".
"test_cmp" is able to handle a missing file just fine, so these
"pre-creations" are mostly confusing. Let's drop them.
Signed-off-by: Martin Ågren
--
This "pre-creation" does protect against the file already
existing, i.e., it coul
[Dropped cc-list the first time around. Apologies to those who receive
this twice...]
On Fri, 2 Aug 2019 at 00:20, Josh Steadmon wrote:
>
> 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
AFAIU, we avoid using `touch` unless we really do want to update the
mtime. Here, we just want to create empty files, so write `>foo`
instead.
Signed-off-by: Martin Ågren
---
...3-pre-commit-and-pre-merge-commit-hooks.sh | 38 ---
1 file changed, 24 insertions(+), 14 deletions(-)
With a failing automatic merge, we want to make sure that we *don't*
call the pre-merge-commit hook and that we (eventually) *do* call the
pre-commit hook.
Signed-off-by: Martin Ågren
---
...3-pre-commit-and-pre-merge-commit-hooks.sh | 30 +++
1 file changed, 30 insertions(+)
di
On Fri, 2 Aug 2019 at 00:20, Josh Steadmon wrote:
> diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
> index 82cd573776..7c4c994858 100644
> --- a/Documentation/githooks.txt
> +++ b/Documentation/githooks.txt
> @@ -103,6 +103,13 @@ The default 'pre-commit' hook, when enabled--
Hi,
I have merged a branch into master.
When on master I do "git log -- some/file", it does not show commits
from merged branch (which I know they changed the file).
I have to add "--full-history" to see the commits.
When I run "git log" (without "-- some/file") I can see the commits
without usin
Hi there,
I've asked this question yesterday on stackoverflow:
https://stackoverflow.com/q/57305719/2622010
And have been confirmed it does look like a bug.
Unfortunately I'm unable to update to latest git revision but a search through
the release notes didn't show anything related to this prob
73 matches
Mail list logo
