Although `test -f` has the same functionality as test_path_is_file(), in
the case where test_path_is_file() fails, we get much better debugging
information.
Replace `test -f` with test_path_is_file() so that future developers
will have a better experience debugging these test cases.
Also, in the
Although `test -f` has the same functionality as test_path_is_file(), in
the case where test_path_is_file() fails, we get much better debugging
information.
Replace `test -f` with test_path_is_file() so that future developers
will have a better experience debugging these test cases.
Also, in the
On Thu, Oct 17, 2019 at 7:35 PM Denton Liu wrote:
> Although `test -f` has the same functionality as test_path_is_file(), in
> the case where test_path_is_file() fails, we get much better debugging
> information.
>
> Replace `test -f` with test_path_is_file() so that future develop
Although `test -f` has the same functionality as test_path_is_file(), in
the case where test_path_is_file() fails, we get much better debugging
information.
Replace `test -f` with test_path_is_file() so that future developers
will have a better experience debugging these test cases. Also, in the
On Thu, Oct 17, 2019 at 7:17 PM Denton Liu wrote:
> Although `test -f` has the same functionality as test_path_is_file(), in
> the case where test_path_is_file() fails, we get much better debugging
> information. Replace `test -f` with test_path_is_file so that future
> developers
Although `test -f` has the same functionality as test_path_is_file(), in
the case where test_path_is_file() fails, we get much better debugging
information. Replace `test -f` with test_path_is_file so that future
developers will have a better experience debugging these test cases.
Signed-off-by
ng is the argument parser thinking your '(' is part of
> the construction of a boolean match formula, and complaining about the
> lack of closing ')'. You can use "-e" to make it clear that it's a
> pattern (just as you'd need to for a pattern that starts
On Tue, Aug 13, 2019 at 03:01:04PM +0900, nanaya wrote:
> I observed this today:
>
> $ git grep -F '('
> fatal: unmatched parenthesis
>
> Which doesn't make sense and I believe shouldn't happen.
At first glance this looks like we're feeding a fixed-
Hi,
I observed this today:
$ git grep -F '('
fatal: unmatched parenthesis
Which doesn't make sense and I believe shouldn't happen.
$ git --version
git version 2.22.0
Duy Nguyen writes:
> Technically 'one' is still tracked (even if it's a directory) so what
> we're doing is right. I'm just not sure if there's some big surprise
> factor here. And whether it's better to pause and double check with
> the user before deleting everything.
I agree to all of the abo
On Tue, May 14, 2019 at 5:37 PM Junio C Hamano wrote:
>
> Duy Nguyen writes:
>
> > $ echo data > one
> > $ git add one
> > $ rm one
> > $ mkdir one
> > $ echo two > one/two
> > $ echo three > one/three
> > $ git checkout one
> > $ ls -l one
> > -rw-r--r-- 1 pclouds pclouds 5 May 14 16:36 one
> >
Duy Nguyen writes:
> $ echo data > one
> $ git add one
> $ rm one
> $ mkdir one
> $ echo two > one/two
> $ echo three > one/three
> $ git checkout one
> $ ls -l one
> -rw-r--r-- 1 pclouds pclouds 5 May 14 16:36 one
>
> Replacing a file is one thing. In this case we're deleting a directory
> and u
$ echo data > one
$ git add one
$ rm one
$ mkdir one
$ echo two > one/two
$ echo three > one/three
$ git checkout one
$ ls -l one
-rw-r--r-- 1 pclouds pclouds 5 May 14 16:36 one
Replacing a file is one thing. In this case we're deleting a directory
and unknown number of files inside (in this case
On Thu, May 02, 2019 at 08:05:57PM +0700, Duy Nguyen wrote:
> The difficulty will be coming up with some sane UI that can
> handle that and not leave too many traps behind. I can't see that UI.
Well, I'm still thinking about it. And perhaps a good UI is not that
far away. The following hacky patch
On Thu, May 2, 2019 at 8:05 PM Duy Nguyen wrote:
> > Part of this is "doctor, it hurts when I stab my eye" :) but I wonder in
> > general whether users are more likely to expect different worktrees to
> > have different views of the refstore, since they way they're created is
> > "I want just this
91a0)
> >> $ git worktree add ../wt master
> >> Preparing worktree (checking out 'master')
> >> HEAD is now at f534c32 4
> >>
> >> > /c/tmp/gt (Branch_702091a0)
> >> $ git branch -D master
> >> error: Cannot delete branch &#x
#x27;)
>> HEAD is now at f534c32 4
>>
>> > /c/tmp/gt (Branch_702091a0)
>> $ git branch -D master
>> error: Cannot delete branch 'master' checked out at 'C:/tmp/wt'
>>
>> #but this is possible:
>>
>> > /c/tmp/gt (Branch_70209
0)
> $ git branch -D master
> error: Cannot delete branch 'master' checked out at 'C:/tmp/wt'
>
> #but this is possible:
>
> > /c/tmp/gt (Branch_702091a0)
> $ git branch -f master HEAD
I admit I didn't see this. But I don't know how far we
'C:/tmp/wt'
#but this is possible:
> /c/tmp/gt (Branch_702091a0)
$ git branch -f master HEAD
#and the other worktree is now corrupted:
> /c/tmp/wt (master)
$ git status
On branch master
Changes to be committed:
(use "git reset HEAD ..." to unstage)
modified:
Eric Sunshine writes:
> On Fri, Mar 8, 2019 at 12:38 AM Junio C Hamano wrote:
>> An unrelated tangent, but what do you think of this patch? In the
>> context of testing "git rm", if foo is a dangling symbolic link,
>> "git rm foo && test_path_is_missing foo" would need something like
>> this to
On Fri, Mar 8, 2019 at 12:38 AM Junio C Hamano wrote:
> An unrelated tangent, but what do you think of this patch? In the
> context of testing "git rm", if foo is a dangling symbolic link,
> "git rm foo && test_path_is_missing foo" would need something like
> this to work correctly, I would think
utor workflow, without spending too much community resources
like reviewers' time (as opposed to the real "here is my itch; let's
improve the system, and please help me doing so").
In any case, I have spent some time with the patch and I think the
changes are generaly OK; some (
On Tue, Mar 5, 2019 at 9:22 AM Rohit Ashiwal wrote:
> I was asking if this patch is good enough to be added to the
> existing code? Does this patch look good?
I didn't review the patch with a critical-enough eye to be able to say
that every change maintains fidelity with the original code. As
men
Eric
I was asking if this patch is good enough to be added to the existing code?
Does this patch look good?
Regards
Rohit
On Tue, Mar 5, 2019 at 8:43 AM Rohit Ashiwal wrote:
> On 2019-03-05 0:42 Eric Sunshine wrote:
> > As with the commit message of 2/3, many of the words in this message
> > are separated by multiple spaced. Please fold out the excess so there
> > is only a single space between words.
> >
> > Also,
Hey Eric
On 2019-03-05 0:42 Eric Sunshine wrote:
> As with the commit message of 2/3, many of the words in this message
> are separated by multiple spaced. Please fold out the excess so there
> is only a single space between words.
>
> Also, no need to say "previously" since readers know that the
On Mon, Mar 4, 2019 at 7:09 AM Rohit Ashiwal wrote:
> Previously we were using `test -(d|f|e|s)` to verify the presence of a
> directory/file, but we already have helper functions, viz, `test_path_is_dir`,
> `test_path_is_file`,`test_path_is_missing`and`test_file_
Previously we were using `test -(d|f|e|s)` to verify the presence of a
directory/file, but we already have helper functions, viz, `test_path_is_dir`,
`test_path_is_file`,`test_path_is_missing`and`test_file_not_empty`
with better functionality.
These helper functions make code
Replace `test -(d|f|e|s)` calls in `t3600-rm.sh`.
Previously we were using `test -(d|f|e|s)` to verify the presence of a
directory/file, but we already have helper functions, viz, `test_path_is_dir`,
`test_path_is_file`, `test_path_is_missing` and `test_file_not_empty`
with better functionality
On Tue, 26 Feb 2019 at 21:02, Rohit Ashiwal wrote:
>
> Hey!
>
> On Wed, Feb 27, 2019 at 1:22 AM Johannes Schindelin
> wrote:
> >
> > We already have `test_path_is_missing`. Why not use that instead of `!
> > test -d` or `! test -f`?
> >
>
> Yes, I
Hey!
On Wed, Feb 27, 2019 at 1:22 AM Johannes Schindelin
wrote:
>
> We already have `test_path_is_missing`. Why not use that instead of `!
> test -d` or `! test -f`?
>
Yes, I think this is better. It will satisfy all the requirements I guess.
Ciao
Rohit
, `test_i18ngrep`.)
> >
>
> Yes, I also think that it should be corrected and I think this(1)
> approach is good as it resonates well with the existing code. I'll
> start working on it and submit the patch as soon as possible.
We already have `test_path_is_missing`. Why not use that instead of `!
test -d` or `! test -f`?
Ciao,
Johannes
Hi Martin
On Tue, Feb 26, 2019 at 10:01 PM Martin Ågren wrote:
>
> > - ! test -d submod &&
> > + ! test_path_is_dir submod &&
>
> Now, here I wonder. This (and other changes like this) means that every
> time the test passes, we see "Directory submod doesn't exist.", which is
> perhap
On Tue, 26 Feb 2019 at 14:43, Rohit Ashiwal via GitGitGadget
wrote:
>
> t3600-rm.sh: Previously we were using `test -(d|f)`
> to verify the presencee of a directory/file, but we
> already have helper functions, viz, test_path_is_dir
> and test_path_is_file with same functionalit
Hi Rohit,
the oneline suggests that this fixes all the tests, but it only fixes
t3600. So maybe use "t3600:" instead of "tests:"?
On Tue, 26 Feb 2019, Rohit Ashiwal via GitGitGadget wrote:
> From: Rohit Ashiwal
>
> t3600-rm.sh: Previously we were using `test -(d|
On Tue, Feb 26, 2019 at 8:42 PM Rohit Ashiwal via GitGitGadget
wrote:
>
> From: Rohit Ashiwal
>
> t3600-rm.sh: Previously we were using `test -(d|f)`
> to verify the presencee of a directory/file, but we
> already have helper functions, viz, test_path_is_dir
> and test_p
From: Rohit Ashiwal
t3600-rm.sh: Previously we were using `test -(d|f)`
to verify the presencee of a directory/file, but we
already have helper functions, viz, test_path_is_dir
and test_path_is_file with same functionality. This
patch will replace `test -(d|f)` calls in t3600-rm.sh.
Signed-off
Previously we were using test -(d|f) to verify the presencee of a
directory/file, but we already have helper functions, viz, test_path_is_dir
and test_path_is_file with same functionality. This patch will replace test
-(d|f) calls in t3600-rm.sh.
Rohit Ashiwal (1):
tests: replace `test -(d|f
Torsten Bögershausen writes:
>> Thanks, both. Eric's proposed message looks good to me too.
>
> Do you want to ammend the patch locally ?
I just amended it; thanks.
rors more compact overall to make them easier to digest[2,3]:
> >>
> >> err 'sed option not portable (use only -n, -e, -f)'
> >
> > That's OK for me - lets see if there are more comments.
>
> Thanks, both. Eric's proposed message looks good to me too.
Do you want to ammend the patch locally ?
Or should I send a new version ?
x27;sed option not portable (use only -n, -e, -f)'
>
> That's OK for me - lets see if there are more comments.
Thanks, both. Eric's proposed message looks good to me too.
\s+-[^efn]\s+/ and err 'Not portable option with sed (use only
>>>> [-n] [-e command] [-f command_file])';
>>>
>>> "sed -n -i -E -e 's/foo/bar/p'" won't be caught with this as an
>>> error, but that's OK ;-).
>>>
On Tue, Jan 22, 2019 at 3:00 PM Torsten Bögershausen wrote:
> On 22.01.19 20:47, Junio C Hamano wrote:
> > tbo...@web.de writes:
> >> -/\bsed\s+-i/ and err 'sed -i is not portable';
> >> +/\bsed\s+-[^efn]\s+/ and err 'Not portable option with
g systems.
>>
>> -/\bsed\s+-i/ and err 'sed -i is not portable';
>> +/\bsed\s+-[^efn]\s+/ and err 'Not portable option with sed (use only
>> [-n] [-e command] [-f command_file])';
>
> "sed -n -i -E -e 's/foo/bar/p'" won
';
> + /\bsed\s+-[^efn]\s+/ and err 'Not portable option with sed (use only
> [-n] [-e command] [-f command_file])';
"sed -n -i -E -e 's/foo/bar/p'" won't be caught with this as an
error, but that's OK ;-).
Is this still an RFC patch?
r, which is GNU).
Change check-non-portable-shell.pl to only accept the portable options:
sed [-n] [-e command] [-f command_file]
Reported-by: SZEDER Gábor
Helped-by: Eric Sunshine
Helped-by: Ævar Arnfjörð Bjarmason
Signed-off-by: Torsten Bögershausen
---
t/check-non-portable-shell.pl | 2 +-
1
Fx
Sent from my iPhone
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/checkout.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index b5e27a5f6d..3ae001ae35 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -438,6 +438,8 @@ static int reset_tree(struct tree *tre
ontrib/completion/git-prompt.sh
+++ b/contrib/completion/git-prompt.sh
@@ -517,8 +517,8 @@ __git_ps1 ()
b="\${__git_ps1_branch_name}"
fi
- local f="$w$i$s$u"
- local gitstring="$c$b${f:+$z$f}$r$p"
+ local f="$w$i$s$u$p&
On 8/16/2018 10:10 AM, Linus Torvalds wrote:
One option that I didn't try to go for - because I just don't know the
less code base well enough - is to basically make the behavior of '-F'
be something like this:
- as long as all the lines are short and well-behaved, and we
I didn't try to go for - because I just don't know the
less code base well enough - is to basically make the behavior of '-F'
be something like this:
- as long as all the lines are short and well-behaved, and we haven't
seen enough lines to fill the screen, act like 'c
-X is a workaround for the previous behavior of -F, but it's not a great
solution. By not sending the terminal init sequence, some things can be
broken, depending on the terminal. For example, some terminals send the
"wrong" sequences for the arrow keys when the terminal doesn
t;> it's covered by this item in the changelog:
>>
>> Don't output terminal init sequence if using -F and file fits on one
>> screen[1]
>
> Side note: that's sad, because we already use X in the default exactly
> for that reason.
And as another note
't output terminal init sequence if using -F and file fits on one
> screen[1]
Side note: that's sad, because we already use X in the default exactly
for that reason.
So apparently "less" was broken for us to fix something that we
already had long solved. The code basically
On Wed, Aug 15, 2018 at 2:29 PM Ævar Arnfjörð Bjarmason
wrote:
>
> FWIW they're not linked from
> http://www.greenwoodsoftware.com/less/download.html but you can just URL
> hack and see releases http://www.greenwoodsoftware.com/less/ and change
> links like http://www.greenwoodsoftware.com/less/le
On Wed, Aug 15 2018, Linus Torvalds wrote:
> Sadly, as of less-530, the behavior of "less -F" is broken enough that
> I think git needs to potentially think about changing the defaults for
> the pager, or people should at least be aware of it.
Downloading & trying
On Wed, Aug 15, 2018 at 1:35 PM Linus Torvalds
wrote:
>
> Sadly, as of less-530, the behavior of "less -F" is broken enough that
> I think git needs to potentially think about changing the defaults for
> the pager, or people should at least be aware of it.
>
> Older v
Sadly, as of less-530, the behavior of "less -F" is broken enough that
I think git needs to potentially think about changing the defaults for
the pager, or people should at least be aware of it.
Older versions of less (at least up to less-487 - March 2017) do not
have this bug.
ct_success 'add --remote-tags' '
+ rm -rf add-tags &&
+ (
+ mkdir add-tags &&
+ cd add-tags &&
+ git init &&
+ git remote add -f --remote-tags origin ../one &&
+ git ta
On Tue, Apr 17, 2018 at 8:17 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>> Makes sense. A possible rewrite (of the entire commit message):
>>
>> worktree: remove: recognize -f as short for --force
>>
>> Many commands support a --force option, fr
Eric Sunshine writes:
> On Tue, Apr 17, 2018 at 2:19 PM, Stefan Beller wrote:
>> The force flag is very common in many commands and is commonly
>> abbreviated with '-f', so add that to worktree removal, too by using
>> OPT__FORCE instead of a self cooked OPT_BOOL
On Tue, Apr 17, 2018 at 2:19 PM, Stefan Beller wrote:
> The force flag is very common in many commands and is commonly
> abbreviated with '-f', so add that to worktree removal, too by using
> OPT__FORCE instead of a self cooked OPT_BOOL for force.
The missing bit of this sen
The force flag is very common in many commands and is commonly
abbreviated with '-f', so add that to worktree removal, too by using
OPT__FORCE instead of a self cooked OPT_BOOL for force.
While at it, add the PARSE_OPT_NOCOMPLETE flag to the force command line
option as forcing a remova
On Mon, Apr 16, 2018 at 6:16 PM, Stefan Beller wrote:
> The force flag is very common in many commands and is commonly
> abbreviated with '-f', so add that to worktree removal, too
>
> Signed-off-by: Stefan Beller
> ---
> diff --git a/builtin/worktree.c b/builtin/w
The force flag is very common in many commands and is commonly
abbreviated with '-f', so add that to worktree removal, too
Signed-off-by: Stefan Beller
---
As a side note:
$ git worktree add ../test HEAD^
$ cd ../test
$ make
$ git worktree remove test
fatal: working trees
Document that providing any of -c, -C, -F and --fixup along with -m
will result in an error. Some variant of this has been errored about
explicitly since 0c091296c0 ("git-commit: log parameter updates.",
2005-08-08), but the documentation was never updated to reflect this.
Wordin
On Wed, Dec 20, 2017 at 2:38 PM, Ævar Arnfjörð Bjarmason
wrote:
> Document that providing any of -c, -C, -F and --fixup along with -m
> will result in an error. Some variant of this has been errored about
> explicitly since 0c091296c0 ("git-commit: log parameter updates.",
>
Document that providing any of -c, -C, -F and --fixup along with -m
will result in an error. Some variant of this has been errored about
explicitly since 0c091296c0 ("git-commit: log parameter updates.",
2005-08-08), but the documentation was never updated to reflect this.
Signed-of
8, 2017 at 11:43 AM, Seth Raymond
> wrote:
>> If a commit is invoked with -F , indicating that the commit
>> message should be read from an existing file, the the
>> prepare-commit-msg and commit-msg hooks do not operate on . The
>> first argument to the hook is always /COMMI
On Mon, Dec 18, 2017 at 11:43 AM, Seth Raymond wrote:
> If a commit is invoked with -F , indicating that the commit
> message should be read from an existing file, the the
> prepare-commit-msg and commit-msg hooks do not operate on . The
> first argument to the hook is always /CO
If a commit is invoked with -F , indicating that the commit
message should be read from an existing file, the the
prepare-commit-msg and commit-msg hooks do not operate on . The
first argument to the hook is always /COMMIT_EDITMSG, rather
than .
Am I wrong in this line of thinking?
-Seth
eck...
>>>
>>> Does this patch make it easier to *set* HEAD to an unborn branch that
>>> d/f conflicts with an existing reference? If so, that might be a
>>> slightly worse UI for users. I'd rather learn about such a problem when
>>> setting HEAD (w
On Sun, Oct 29, 2017 at 09:05:44AM +0900, Junio C Hamano wrote:
> In short, unless you are a binary packager on a platform whose
> native shell is ksh and who refuses to depend on tools that are not
> default/native on the platform, you'd be OK?
Yes.
> > I'd recommend an explicit test for this.
"brian m. carlson" writes:
> There is discussion in the Austin Group issue tracker about adding this
> feature to POSIX, but it's gotten bogged down over lexical versus
> dynamic scoping. Everyone agrees that it's a desirable feature, though.
> ...
In short, unless you are a binary packager on
On Wed, Oct 25, 2017 at 11:32:51PM -0700, Jeff King wrote:
> On Wed, Oct 25, 2017 at 10:03:09AM +0200, Michael Haggerty wrote:
>
> > > Yeah. It's supported by dash and many other shells, but we do try to
> > > avoid it[1]. I think in this case we could just drop it (but keep
> > > setting the "loc
On Wed, Oct 25, 2017 at 10:03:09AM +0200, Michael Haggerty wrote:
> > Yeah. It's supported by dash and many other shells, but we do try to
> > avoid it[1]. I think in this case we could just drop it (but keep
> > setting the "local foo" ones to empty with "foo=".
>
> I do wish that we could allow
404-update-ref-errors.sh b/t/t1404-update-ref-errors.sh
>>>> @@ -34,6 +34,86 @@ test_update_rejected () {
>>>> +# Test adding and deleting D/F-conflicting references in a single
>>>> +# transaction.
>>>> +df_test() {
>>>> + local prefix=
-34,6 +34,86 @@ test_update_rejected () {
>>> +# Test adding and deleting D/F-conflicting references in a single
>>> +# transaction.
>>> +df_test() {
>>> + local prefix="$1"
>>> + shift
>>> + local pack=:
>>
>&
On Tue, Oct 24, 2017 at 12:19:26PM -0400, Eric Sunshine wrote:
> On Tue, Oct 24, 2017 at 11:16 AM, Michael Haggerty
> wrote:
> > diff --git a/t/t1404-update-ref-errors.sh b/t/t1404-update-ref-errors.sh
> > @@ -34,6 +34,86 @@ test_update_rejected () {
> > +# Test
On Tue, Oct 24, 2017 at 11:16 AM, Michael Haggerty wrote:
> diff --git a/t/t1404-update-ref-errors.sh b/t/t1404-update-ref-errors.sh
> @@ -34,6 +34,86 @@ test_update_rejected () {
> +# Test adding and deleting D/F-conflicting references in a single
> +# transaction.
> +df_test() {
It is currently not allowed, in a single transaction, to add one
reference and delete another reference if the two reference names D/F
conflict with each other (e.g., like `refs/foo/bar` and `refs/foo`).
The reason is that the code would need to take locks
$GIT_DIR/refs/foo.lock
$GIT_DIR
(apologies to those whose email systems barfed on my domain being
badly configured WRT MX record, i have been assured by my admin it's
been fixed.)
reading "man git-config", first, it seems awkward that the "-f"
option is explained in terms of GIT_CONFIG even when
On 10/06/2017 07:16 PM, Jeff King wrote:
> On Fri, Oct 06, 2017 at 07:09:10PM +0200, Michael Haggerty wrote:
>
>> I do have one twinge of uneasiness at a deeper level, that I haven't had
>> time to check...
>>
>> Does this patch make it easier to *set* H
On Fri, Oct 06, 2017 at 07:09:10PM +0200, Michael Haggerty wrote:
> I do have one twinge of uneasiness at a deeper level, that I haven't had
> time to check...
>
> Does this patch make it easier to *set* HEAD to an unborn branch that
> d/f conflicts with an existing referenc
xpected this case to fail.
>
> 2. When resolving symbolic refs, we typically do not use
> the READING flag because we want to resolve even
> symrefs that point to unborn refs. Even if those unborn
> refs could not actually be written because of d/f
> conf
es-merge code does this, and
before the fix in the prior commit t3308 erroneously
expected this case to fail.
2. When resolving symbolic refs, we typically do not use
the READING flag because we want to resolve even
symrefs that point to unborn refs. Even if those unborn
"git commit-tree -F ", unlike "cat | git
commit-tree" (i.e. feeding the same contents from the standard
input), added a missing final newline when the input ended in an
incomplete line.
Correct this inconsistency by leaving the incomplete line as-is,
as erring on the side
Ross Kabus writes:
> On Thu, Sep 7, 2017 at 9:35 PM, Junio C Hamano wrote:
>> commit-tree: do not complete line in -F input
>>
>> "git commit-tree -F ", unlike "cat | git
>> commit-tree" (i.e. feeding the same contents from the standa
On Thu, Sep 7, 2017 at 9:35 PM, Junio C Hamano wrote:
> commit-tree: do not complete line in -F input
>
> "git commit-tree -F ", unlike "cat | git
> commit-tree" (i.e. feeding the same contents from the standard
> input), added a missing final
Ross Kabus writes:
> This change makes it such that commit-tree -F never appends a newline
> character to the supplied commit message (either from file or stdin).
>
> Previously, commit-tree -F would always append a newline character to
> the text brought in from file or stdi
This change makes it such that commit-tree -F never appends a newline
character to the supplied commit message (either from file or stdin).
Previously, commit-tree -F would always append a newline character to
the text brought in from file or stdin. This has caused confusion in a
number of ways
These are taken from https://github.com/pclouds/git/commits/fopen-or-warn
cf.
with a few bits salvaged from its v2 version.
Ramsay Jones (1):
git_fopen: fix a sparse 'not declared' warning
Nguyễn Thái Ngọc Duy (9):
use xfopen() in more places
clone: use xfopen() instead of fopen()
confi
kwset.[ch] codepath, see the "Even when
-F..." comment in grep.c. This only kicks for the non-ASCII case:
$ GIT_PERF_REPEAT_COUNT=10 GIT_PERF_LARGE_REPO=~/g/linux
GIT_PERF_7821_GREP_OPTS=' -i' ./run p7821-grep-engines-fixed.sh
[...]
Test
Add a performance comparison test of log --grepgrep regex engines
given fixed strings.
See the preceding fixed-string t/perf change ("perf: add a comparison
test of grep regex engines with -F", 2017-04-21) for notes about this,
in particular this mostly tests exactly the same codepat
-4,6 +4,29 @@ test_description='git grep in binary files'
. ./test-lib.sh
+nul_match () {
+ matches=$1
+ flags=$2
+ pattern=$3
+ pattern_human=$(echo "$pattern" | sed 's/Q//g')
+
+ if test "$matches" = 1
+ then
+
.40(1.28+0.43)
7821.13: extended grep æ 0.39(1.28+0.44)
7821.14: perl grep æ 0.39(1.29+0.44)
This test needs to be run with GIT_PERF_7821_GREP_OPTS=' -i' to avoid
going through the same kwset.[ch] codepath, see the "Even when -
-4,6 +4,29 @@ test_description='git grep in binary files'
. ./test-lib.sh
+nul_match () {
+ matches=$1
+ flags=$2
+ pattern=$3
+ pattern_human=$(echo "$pattern" | sed 's/Q//g')
+
+ if test "$matches" = 1
+ then
+
Ævar Arnfjörð Bjarmason writes:
>> It somehow was unintuitive that 0 expected failure and 1 expected
>> success, but it probably was just me.
>
> Except this. The wildmatch uses the same idiom, and I think it makes
> sense. 1 = true, 0 = false, ... when all we wanted was
> "does this match".
OK.
-4,6 +4,29 @@ test_description='git grep in binary files'
. ./test-lib.sh
+nul_match () {
+ status=$1
+ flags=$2
+ pattern=$3
+ pattern_human=$(echo "$pattern" | sed 's/Q//g')
+
+ if test "$status" = 1
+ then
+
gt; Double quote around "$pattern"?
>
>> +
>> + if test $status = "1"
>
> Double quote around "$status" and drop double quote around "1"
> (which is clearly a literal string without any funnies) instead?
>
>> + then
>> +
1 - 100 of 325 matches
Mail list logo
