Am 06.08.19 um 18:36 schrieb Carlo Marcelo Arenas Belón:
> 94da9193a6 (grep: add support for PCRE v2, 2017-06-01) didn't include
> a way to override the system allocator, and so it is incompatible with
> USE_NED_ALLOCATOR. The problem was made visible when an attempt to
> avoid a leak in a data st
Rohit Ashiwal writes:
> diff --git a/builtin/rebase.c b/builtin/rebase.c
> index db6ca9bd7d..3c195ddc73 100644
> --- a/builtin/rebase.c
> +++ b/builtin/rebase.c
> ...
> @@ -511,6 +523,8 @@ int cmd_rebase__interactive(int argc, const char **argv,
> const char *prefix)
> argc = parse_options
Pratyush Yadav writes:
> I'm not too optimistic on finding someone to run this project. I asked
> on the list who the maintainer is [0], and no one came up. The repo at
> [1] also seems abandoned.
In the meantime until somebody steps up, I might run my own copy.
I need to allocate a block of ti
Rohit Ashiwal writes:
> On Tue, 06 Aug 2019 14:58:38 -0700 Junio C Hamano wrote:
>>
>> [...]
>> * ra/rebase-i-more-options (2019-07-23) 4 commits
>> ...
>> Needs a bit of fixups, at least.
>> [...]
>
> This patch series was re-sent as a new topic, available here[1].
Thanks for a pointer.
Dur
On 2019-08-06 at 23:43:20, Jeff King wrote:
> On Tue, Aug 06, 2019 at 10:58:53PM +, brian m. carlson wrote:
> > Sorry, I hadn't had a chance to look at this series in depth, but I was
> > wondering: could we not just accept two separate "--" arguments, and if
> > there are two of them, interpre
Hi Junio
On Tue, 06 Aug 2019 14:58:38 -0700 Junio C Hamano wrote:
>
> [...]
> * ra/rebase-i-more-options (2019-07-23) 4 commits
> - SQUASH???
> - rebase -i: support --committer-date-is-author-date
> - sequencer: add NULL checks under read_author_script
> - rebase -i: add --ignore-whitespace f
On Tue, Aug 06, 2019 at 10:58:53PM +, brian m. carlson wrote:
> On 2019-08-06 at 14:38:30, Jeff King wrote:
> > It's hard for scripted uses of rev-list, etc, to avoid option injection
> > from untrusted arguments, because revision arguments must come before
> > any "--" separator. I.e.:
> >
>
Existing documentation on revision walks seems to be primarily intended
as a reference for those already familiar with the procedure. This
tutorial attempts to give an entry-level guide to a couple of bare-bones
revision walks so that new Git contributors can learn the concepts
without having to wa
On Thu, Jul 25, 2019 at 11:25:02AM +0200, Johannes Schindelin wrote:
> 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:
On Wed, Jul 24, 2019 at 04:32:53PM -0700, Jonathan Tan wrote:
> Thanks - I think this is a useful guide to what can be a complicated
> topic. It looks good overall; I just have some minor comments below.
>
> > diff --git a/Documentation/Makefile b/Documentation/Makefile
> > index 76f2ecfc1b..91e5d
On 2019-08-06 at 14:38:30, Jeff King wrote:
> It's hard for scripted uses of rev-list, etc, to avoid option injection
> from untrusted arguments, because revision arguments must come before
> any "--" separator. I.e.:
>
> git rev-list "$revision" -- "$path"
>
> might mistake "$revision" for an
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.
There are a few last-minute fix-up
> > > +
> > > + test_i18ngrep ! CONFLICT out &&
> > > + test_i18ngrep ! BUG: err &&
> >
> > The BUG is gone. But should it not use i18ngrep? BUG() isn't localized.
>
> Technically, yes, you're right. However, this line's purpose isn't
> correctness of the test but documenta
On Tue, Aug 6, 2019 at 1:28 PM Emily Shaffer wrote:
>
> On Mon, Aug 05, 2019 at 03:33:50PM -0700, Elijah Newren wrote:
> > Ever since commit 8c8e5bd6eb33 ("merge-recursive: switch directory
> > rename detection default", 2019-04-05), the default handling with
> > directory rename detection was to
On Tue, Aug 06, 2019 at 09:27:30AM -0400, Jeff King wrote:
> On Tue, Aug 06, 2019 at 06:59:21AM +0200, Christian Couder wrote:
>
> > When Git Rev News was started I thought that there could be such a
> > group effort to encourage each other to publish articles in it, but I
> > must say that outsid
On Tue, Aug 06, 2019 at 08:19:15AM -0400, Derrick Stolee wrote:
> On 8/6/2019 12:52 AM, Andrew Ardill wrote:
> > On Tue, 6 Aug 2019 at 11:51, Emily Shaffer wrote:
> >
> >> Are folks interested in writing and reviewing this kind of content?
>
> I am interested in writing and reviewing! Here are s
On Tue, Aug 06, 2019 at 09:20:52AM -0400, Jeff King wrote:
> On Mon, Aug 05, 2019 at 06:49:35PM -0700, Emily Shaffer wrote:
>
> > Are folks interested in writing and reviewing this kind of content? Any
> > ideas for where we may be able to host (maybe git-scm)?
>
> I think it would make sense to
On Mon, Aug 05, 2019 at 03:33:50PM -0700, Elijah Newren wrote:
> 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. H
Junio C Hamano writes:
>> +static char warn_show_forced_updates[] =
>> +N_("Fetch normally indicates which branches had a forced update,\n"
>> + "but that check has been disabled. To re-enable, use
>> '--show-forced-updates'\n"
>> + "flag or run 'git config fetch.showForcedUpdates true'.");
Hi All,
I don't recall when this was previously discussed, but the timing is
relevant at 2.23.0. With switch and restore commands coming in this release,
I was wondering how long checkout will be provided for compatibility - or if
it will be deprecated at all. I assume that enhancements should onl
I started trying to make a stab at implementing this, but the code
wasn't standing out for it. Hopefully somebody else has poked at it
before:
I'd like to have a --quiet option for git-bundle, such that only errors
are sent to stderr, and not the packing progress.
This is towards a better increme
Jeff King writes:
> git commit -m 'buggy commit'
> echo fix >>file.c
> git commit --amend ;# oops, should have been "-a"
> git push
>
> But perhaps that gets to the heart of the matter. Could we perhaps be
> providing a more detailed summary of what happened for an --amend? I.e.,
> to sum
On 8/6/19 11:52 PM, Junio C Hamano wrote:
Pratyush Yadav writes:
If there are no comments/objections with this patch, can it be merged
please?
It usually works the other way around (no comments by default means
no interests), but sadly, a larger problem with this area is that
there currently
Pratyush Yadav writes:
> If there are no comments/objections with this patch, can it be merged
> please?
It usually works the other way around (no comments by default means
no interests), but sadly, a larger problem with this area is that
there currently is nobody who is actively working on main
On Tue, Aug 06, 2019 at 01:38:17PM -0400, Jeff King wrote:
> Nothing about "--" is changed by my series; it will still stop option
> interpretation in rev-list and in other commands. But as before,
> rev-list (and other Git commands that use the revision.c parser) use it
> to separate revisions and
Josh Steadmon writes:
> 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
>
On Tue, Aug 06, 2019 at 10:54:47AM -0700, Junio C Hamano wrote:
> Jean-Noël Avila writes:
>
> > Signed-off-by: Jean-Noël Avila
> > ---
> > builtin/checkout.c | 2 +-
> > builtin/fetch.c| 15 +++
> > 2 files changed, 12 insertions(+), 5 deletions(-)
>
> Thanks. Folks, does th
On August 6, 2019 1:38 PM, Jeff King wrote:
> To: Randall S. Becker
> Cc: 'Junio C Hamano' ; git@vger.kernel.org
> Subject: Re: [PATCH 0/3] --end-of-options marker
>
> On Tue, Aug 06, 2019 at 12:36:26PM -0400, Randall S. Becker wrote:
>
> > > > This series provides an alternative to "--" to stop
Jean-Noël Avila writes:
> Signed-off-by: Jean-Noël Avila
> ---
> builtin/checkout.c | 2 +-
> builtin/fetch.c| 15 +++
> 2 files changed, 12 insertions(+), 5 deletions(-)
Thanks. Folks, does this look sensible (it does to me)?
> diff --git a/builtin/checkout.c b/builtin/chec
Junio C Hamano writes:
> I do agree that it is sensible to avoid doing any funky thing during
> the virtual base merges, whose result is much less observable (hence
> harder to form the right mental model in end user's head) than the
> outermost merge. Do we want to allow this for inner merges w
rebase am already has this flag to "lie" about the author date
by changing it to the committer (current) date. Let's add the same
for interactive machinery.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt| 6 ++--
builtin/rebase.c| 17 +
The previous commit introduced --ignore-date flag to interactive
rebase, but the name is actually very vague in context of rebase -i
since there are two dates we can work with. Add an alias to convey
the precise purpose.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt | 1 +
builti
The purpose of amend_author was to free() the malloc()'d string
obtained from get_author(). But the name does not actually convey
this purpose. Rename it to something meaningful.
Signed-off-by: Rohit Ashiwal
---
sequencer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git
The previous versions of this patch series were sent here[1]. This patch
accounts for all the suggestions mentioned there and also introduces a flag
--ignore-date (also aliased --author-date-is-committer-date).
Caveat:
The flag --ignore-date (of rebase -am) silently overrides the
There are two backends available for rebasing, viz, the am and the
interactive. Naturally, there shall be some features that are
implemented in one but not in the other. One such flag is
--ignore-whitespace which indicates merge mechanism to treat lines
with only whitespace changes as unchanged. Wi
read_author_script reads name, email and author date from the author
script. However, it does not check if the arguments are NULL. Adding
NULL checks will allow us to selectively get the required value, for
example:
char *date;
if (read_author_script(_path_, NULL, NULL, &date, _int_))
rebase am already has this flag to "lie" about the committer date
by changing it to the author date. Let's add the same for
interactive machinery.
Signed-off-by: Rohit Ashiwal
---
Documentation/git-rebase.txt| 8 +++-
builtin/rebase.c| 20 +++---
sequence
On Tue, Aug 06, 2019 at 12:36:26PM -0400, Randall S. Becker wrote:
> > > This series provides an alternative to "--" to stop option parsing
> > > without indicating that further arguments are pathspecs.
>
> Would this offer the opportunity to, in the long term, supply options to
> external diff e
On Tue, Aug 06, 2019 at 09:24:38AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > It's hard for scripted uses of rev-list, etc, to avoid option injection
> > from untrusted arguments, because revision arguments must come before
> > any "--" separator. I.e.:
> >
> > git rev-list "$revis
On Tue, Aug 6, 2019 at 10:26 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > I know this bug doesn't satisfy the normal criteria for making it into
> > 2.23 (it's a bug that was present in 2.22 rather than a regression in
> > 2.23), but given that it's a BUG() condition, I was hoping it
On Tue, Aug 6, 2019 at 9:57 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > 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
Elijah Newren writes:
> I know this bug doesn't satisfy the normal criteria for making it into
> 2.23 (it's a bug that was present in 2.22 rather than a regression in
> 2.23), but given that it's a BUG() condition, I was hoping it is
> important and safe enough to include anyway.
For maintenance
Signed-off-by: Jean-Noël Avila
---
builtin/checkout.c | 2 +-
builtin/fetch.c| 15 +++
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 91f8509f85..6123f732a2 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@
Elijah Newren writes:
> 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 b
Carlo Marcelo Arenas Belón writes:
> Junio, could you comment in my assumption that the use of grep in
> revision.c doesn't require initializing a PCRE2 global context and
> therefore not doing the cleanup?
Many callers of setup_revisions() do so only to run two-thing diffs
(e.g. run_diff_files
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 it is done
for PCRE1.
Signed-off-by: Carlo Ma
63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09) didn't include a way
to override the system alocator, and so it is incompatible with
USE_NED_ALLOCATOR as reported by Dscho[1] (in similar code from PCRE2)
Make the minimum change possible to ensure this combination is supported
by extending grep_ini
94da9193a6 (grep: add support for PCRE v2, 2017-06-01) didn't include
a way to override the system allocator, and so it is incompatible with
USE_NED_ALLOCATOR. The problem was made visible when an attempt to
avoid a leak in a data structure that is created by the library was
passed to NED's free f
This series is a candidate reroll for cb/pcre2-chartables-leakfix, that
hopefully addresses the root cause of the problem reported by Dscho in
Windows, where the PCRE2 library wasn't aware of the custom allocator and
was returning a pointer created with the system malloc but passing it to
NED's fre
On August 6, 2019 12:25 PM, Junio wrote:
> Jeff King writes:
>
> > It's hard for scripted uses of rev-list, etc, to avoid option
> > injection from untrusted arguments, because revision arguments must
> > come before any "--" separator. I.e.:
> >
> > git rev-list "$revision" -- "$path"
> >
> >
On 06/08/2019 04:53, Junio C Hamano wrote:
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
Jeff King writes:
> It's hard for scripted uses of rev-list, etc, to avoid option injection
> from untrusted arguments, because revision arguments must come before
> any "--" separator. I.e.:
>
> git rev-list "$revision" -- "$path"
>
> might mistake "$revision" for an option (with rev-list, tha
On Tue, 6 Aug 2019 17:54:20 +0200
Mateusz Loskot wrote:
> On Tue, 6 Aug 2019 at 16:04, Jason Sewall wrote:
> >
> > Submodules are great, and I used them at work. The problem is, people
> > wind up cloning my repos without --recursive and then nothing works
> > for them, because the submodules w
On Tue, 6 Aug 2019 at 16:04, Jason Sewall wrote:
>
> Submodules are great, and I used them at work. The problem is, people
> wind up cloning my repos without --recursive and then nothing works
> for them, because the submodules weren't populated and those
> ultimately are needed to build my code.
If there are no comments/objections with this patch, can it be merged
please?
On 8/4/19 8:09 PM, Pratyush Yadav wrote:
If the toplevel window for the window being destroyed is the main window
(aka "."), then simply destroying it means the cleanup tasks are not
executed like saving the commit me
On Tue, Aug 06, 2019 at 08:03:07AM -0400, Derrick Stolee wrote:
> > On the other hand, one of my fun side-projects is to run some
> > semi-automated and souped-up CI builds of currently cooking topics,
> > which include a custom GETTEXT_POISON mode [1], where the poisoned
> > translated progress ou
Now that --end-of-options is available for any users of
setup_revisions() or parse_options(), which should be effectively
everywhere, we can guide people to use it for all their disambiguating
needs.
Signed-off-by: Jeff King
---
Documentation/gitcli.txt | 6 ++
1 file changed, 6 insertions(+
The revision option parser recently learned about --end-of-options, but
that's not quite enough for all callers. Some of them, like git-log,
pick out some options using parse_options(), and then feed the remainder
to setup_revisions(). For those cases we need to stop parse_options()
from finding mo
There's currently no robust way to tell Git that a particular option is
meant to be a revision, and not an option. So if you have a branch
"refs/heads/--foo", you cannot just say:
git rev-list --foo
You can say:
git rev-list refs/heads/--foo
But that breaks down if you don't know the refnam
It's hard for scripted uses of rev-list, etc, to avoid option injection
from untrusted arguments, because revision arguments must come before
any "--" separator. I.e.:
git rev-list "$revision" -- "$path"
might mistake "$revision" for an option (with rev-list, that would make
it an error, but so
Submodules are great, and I used them at work. The problem is, people
wind up cloning my repos without --recursive and then nothing works
for them, because the submodules weren't populated and those
ultimately are needed to build my code.
I can see why --recursive isn't the default for git clone;
On Tue, Aug 06, 2019 at 06:59:21AM +0200, Christian Couder wrote:
> When Git Rev News was started I thought that there could be such a
> group effort to encourage each other to publish articles in it, but I
> must say that outside the group of editors (currently Jakub, Markus,
> Gabriel and me) it
On Mon, Aug 05, 2019 at 06:49:35PM -0700, Emily Shaffer wrote:
> Are folks interested in writing and reviewing this kind of content? Any
> ideas for where we may be able to host (maybe git-scm)?
I think it would make sense to have blog.git-scm.com (and .org) with
this content. I'd be happy to dea
On Thu, Aug 01, 2019 at 01:24:17PM -0400, Jeff Hostetler wrote:
> > By the way, I wondered why trace2's existing config reading did not
> > cause us to segfault because of this. It is because it invented the
> > "very early config" function which always ignores some config sources
> > (working aro
On Tue, Aug 06, 2019 at 08:27:58AM -0400, Jeff King wrote:
> diff --git a/config.c b/config.c
> index 3900e4947b..cc637363bb 100644
> --- a/config.c
> +++ b/config.c
> @@ -275,7 +275,7 @@ static int include_by_branch(const char *cond, size_t
> cond_len)
> int flags;
> int ret;
>
Since the previous commit, our invariant that the_repository is never
NULL is restored, and we can stop being defensive in include_by_branch().
We can confirm the fix by showing that an onbranch config include will
not cause a segfault when run outside a git repository. I've put this in
t1309-earl
We initialize the trace2 system in the common main() function so that
all programs (even ones that aren't builtins) will enable tracing. But
trace2 startup is relatively heavy-weight, as we have to actually read
on-disk config to decide whether to trace. This can cause unexpected
interactions with
Commit 85fe0e800c (config: work around bug with includeif:onbranch and
early config, 2019-07-31) tests that our early config-reader does not
access the file mentioned by includeIf.onbranch:refs/heads/master.path.
But it would never do so even if the feature were implemented, since the
onbranch matc
On Thu, Aug 01, 2019 at 01:24:17PM -0400, Jeff Hostetler wrote:
> > By the way, I wondered why trace2's existing config reading did not
> > cause us to segfault because of this. It is because it invented the
> > "very early config" function which always ignores some config sources
> > (working aro
On 8/6/2019 12:52 AM, Andrew Ardill wrote:
> On Tue, 6 Aug 2019 at 11:51, Emily Shaffer wrote:
>
>> Are folks interested in writing and reviewing this kind of content?
I am interested in writing and reviewing! Here are some topics I am
interested in writing:
* Updates to the commit-graph featur
On 8/6/2019 5:21 AM, SZEDER Gábor wrote:
> On Mon, Aug 05, 2019 at 09:43:41AM -0700, Derrick Stolee via GitGitGadget
> wrote:
>
>> In such a case, the reading
>> process outputs the following message to stderr:
>>
>> warning: commit-graph chain does not match
>>
>> These warnings are output
Dear all,
Please find attach purchase inquiry and advice us if you can supply.
send us catalogue with price list as well as company information
I am waiting for your urgent reply so that I can send revise order.
Best regards,
Ali Bahadir ORAL
Procurement engineer
AK GROUP ENGINEERING INS.
On Mon, Aug 05, 2019 at 09:43:41AM -0700, Derrick Stolee via GitGitGadget wrote:
> In such a case, the reading
> process outputs the following message to stderr:
>
> warning: commit-graph chain does not match
>
> These warnings are output in the test suite, but ignored. By
> checking the s
Most of the code stolen from[1] to easy on comparison and including
the deficiency of setting the global context even for patterns that
won't need it.
Ideally, the call from grep_init could be moved to a place where it
could be set without needing a lock and at least with this approach
we have a p
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 it is done
for PCRE1.
Signed-off-by: Carlo Ma
This is an incomplete reroll for cb/pcre2-chartables-leakfix that attempts
to address the root cause of the problem reported[1] by Dscho with PCRE2
and that is that until now PCRE and NED never worked together.
The first patch is likely correct but since I'd been unable to replicate
the issue I ca
63e7e9d8b6 ("git-grep: Learn PCRE", 2011-05-09) didn't include a way
to override the system alocator, and so it is incompatible with
USE_NED_ALLOCATOR as reported by Dscho[1] (in similar code from PCRE2)
Make the minimum change possible to ensure this combination is supported
[1] https://public-i
Hi Matheus,
On Tue, Aug 6, 2019 at 4:54 AM Matheus Tavares Bernardino
wrote:
>
> Here's my report from last week:
> https://matheustavares.gitlab.io/posts/week-11-wip-grep-protecting-textconv-and-submodules
Thank you for another great report!
> I'm working to protect the operations I left behin
78 matches
Mail list logo
