* Re: Refreshing index timestamps without reading content
From: Duy Nguyen @ 2017-01-09 12:02 UTC (permalink / raw)
To: Quentin Casasnovas; +Cc: Git Mailing List
In-Reply-To: <20170105112359.GN8116@chrystal.oracle.com>
On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas
<quentin.casasnovas@oracle.com> wrote:
> Hi guys,
>
> Apologies if this is documented somewhere, I have fairly bad search vudu
> skills.
>
> I'm looking for a way to cause a full refresh of the index without causing
> any read of the files, basically telling git "trust me, all worktree files
> are matching the index, but their stat information have changed". I have
> read about the update-index --assume-unchanged and --skip-worktree flags in
> the documentation, but these do not cause any index refresh - rather, they
> fake that the respective worktree files are matching the index until you
> remove those assume-unchanged/skip-worktree bits.
>
> This might sound like a really weird thing to do, but I do have a use case
> for it - we have some build farm setup where the resulting objects of a
> compilation are stored on a shared server. The source files are not stored
> on the shared server, but locally on each of the build server (as to
> decrease network load and make good use of local storage as caches).
>
> We then use an onion filesystem to mount the compiled objects on top of the
> local sources - and change the modification time of the source to be older
> than the object files, so that on subsequent builds, make does not rebuild
> the whole world.
>
> This works fine except for one thing, after changing the mtime of the
> source files, the first subsequent git command needing to compare the tree
> with the index will take a LONG time since it will read all of the object
> content:
>
> cd linux-2.6
>
> # Less than a second when the index is up to date
> time git status > /dev/null
> git status 0.06s user 0.09s system 172% cpu 0.087 total
> ~~~~~~~~~~~
>
> # Change the mtime..
> git ls-tree -r --name-only HEAD | xargs -n 1024 touch
>
> # Now 30s..
> time git status > /dev/null
> git status 2.73s user 1.79s system 13% cpu 32.453 total
> ~~~~~~~~~~~~
>
> The timing information above was captured on my laptop SSD and the penalty
> is obviously much higher on spinning disks - especially when this operation
> is done on *hundreds* of different work tree in parallel, all hosted on the
> same filesystem (it can take tens of minutes!).
>
> Is there any way to tell git, after the git ls-tree command above, to
> refresh its stat cache information and trust us that the file content has
> not changed, as to avoid any useless file read (though it will obviously
> will have to stat all of them, but that's not something we can really
> avoid)
I don't think there's any way to do that, unfortunately.
> If not, I am willing to implement a --assume-content-unchanged to the git
> update-index if you guys don't see something fundamentally wrong with this
> approach.
If you do that, I think you should go with either of the following options
- Extend git-update-index --index-info to take stat info as well (or
maybe make a new option instead). Then you can feed stat info directly
to git without a use-case-specific "assume-content-unchanged".
- Add "git update-index --touch" that does what "touch" does. In this
case, it blindly updates stat info to latest. But like touch, we can
also specify mtime from command line if we need to. It's a bit less
generic than the above option, but easier to use.
Caveat: The options I'm proposing can be rejected. So maybe wait a bit
to see how people feel and perhaps send an RFC patch, again to gauge
the reception.
--
Duy
^ permalink raw reply
* Re: Test failures when Git is built with libpcre and grep is built without it
From: Jeff King @ 2017-01-09 11:27 UTC (permalink / raw)
To: A. Wilcox; +Cc: git
In-Reply-To: <58736B2A.40003@adelielinux.org>
On Mon, Jan 09, 2017 at 04:51:22AM -0600, A. Wilcox wrote:
> Interestingly enough, you seem to be right. The failure is very
> bizarre and has nothing to do with system /bin/grep:
>
> test_must_fail: command succeeded: git grep -G -F -P -E a\x{2b}b\x{2a}c ab
> not ok 142 - grep -G -F -P -E pattern
> #
> # >empty &&
> # test_must_fail git grep -G -F -P -E "a\x{2b}b\x{2a}c"
> ab >actual &&
> # test_cmp empty actual
> #
>
> However:
>
> elaine trash directory.t7810-grep # git grep -G -F -P -E
> a\x{2b}b\x{2a}c ab >actual
> fatal: command line, 'ax{2b}bx{2a}c': Invalid contents of {}
Hrm, it looks like your shell eats the backslashes in a double-quoted
string.
What does:
printf '%s\n' "a\x{2b}b\x{2a}c"
show?
I'm not sure if that's related or not. And as you said your shell is
bash, that seems weird. Lots of other people run bash, and we haven't
gotten a report (and your version isn't bleeding edge).
That said, the "invalid contents" error message is expected. What's
confusing is that the command returned success. The error comes from
compile_regexp(), which sees that regcomp() failed. It calls
compile_regexp_failed(), which calls die(), which should end in
exit(128). But the shell sees the exit code as 0. Weird.
Your example run after shows that the correct exit code comes out of
git. What does:
./t7810-grep.sh -x --verbose-only=142
say? That should enable "set -x" in the shell just for that test.
-Peff
PS In my repo, the test that is failing for you is actually 145. Are you
trying with a version of git older than v2.7.x? If so, you might
double-check that the problem persists on the latest "master". I
don't know of any particular fixes, but it's worth a shot.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (preview)
From: Johannes Schindelin @ 2017-01-09 11:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqmvf0yke0.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Sun, 8 Jan 2017, Junio C Hamano wrote:
> * js/difftool-builtin (2017-01-08) 4 commits
> - t7800: run both builtin and scripted difftool, for now
> - difftool: implement the functionality in the builtin
> - difftool: add a skeleton for the upcoming builtin
> - git_exec_path: avoid Coverity warning about unfree()d result
>
> Rewrite a scripted porcelain "git difftool" in C.
>
> What's the doneness of this topic?
There was only one bug report since the first iteration, and it has been
fixed as of v4.
The git_exec_path patch is a bit unrelated and should probably be split
out.
The "t7800: run both" patch should not be merged to `next` (or beyond).
I will prepare a proper v5 soon that replaces the t7800 patch by a patch
retiring the Perl script to contrib/.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v3 08/21] Documentation/git-update-index: talk about core.splitIndex config var
From: Duy Nguyen @ 2017-01-09 11:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, git, Ævar Arnfjörð Bjarmason,
Christian Couder
In-Reply-To: <xmqqshou35zr.fsf@gitster.mtv.corp.google.com>
On Sun, Jan 8, 2017 at 4:38 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>> It feels strange that when I do things one way, you suggest another
>> way, and the next time in a similar situation when I do things the way
>> you suggested previously, then you suggest the way I did it initially
>> the first time...
>
> Perhaps because neither is quite satisfactory and I am being forced
> to choose between the two unsatifactory designs? In any case, I
> mostly am and was pointing out the issues and not saying the other
> one is the most preferred solution in these threads.
>
> I think there should just be one authoritative source of the truth,
Either that, or we make sure all sources of truth are consistent. In
this case, 'update --split-index' could update core.splitIndex if it
finds that the config tells a different story. As a plumbing though, I
rather leave update-index do simple things, even if it means the user
has to clean up after it (or before it) with "git config -unset
core.splitIndex". Another option is refuse to execute --split-index in
the presence of (conflicting) core.splitIndex. We kind of force the
user to keep all sources of truth consistent this way while leaving a
back door ("git -c core.splitIndex= update-index") for those who need
tools to recover from a bad case.
> and I have always thought it should be the bit set in the index file
> when the command line option is used, because that was the way the
> feature was introduced first and I am superstitious about end-user
> inertia. And from that point of view, no matter how you make this
> new "config" thing interact with it, it would always give a strange
> and unsatifactory end-user experience, at least to me.
>
> Perhaps we should declare that config will be the one and only way
> in the future and start deprecating the command line option way.
> That will remove the need for two to interact with each other.
>
> I dunno.
--
Duy
^ permalink raw reply
* Re: [PATCH] connect: handle putty/plink also in GIT_SSH_COMMAND
From: Johannes Schindelin @ 2017-01-09 11:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Segev Finer
In-Reply-To: <xmqqh958y44c.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Mon, 9 Jan 2017, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > If you feel strongly about your contrived examples possibly being
> > affected by this patch, we could easily make this conditional on
> >
> > 1) no '&&' or '||' being found on the command-line, and
> > 2) argv[0] not containing an '='
> >
> > Another approach would be to verify that argv[i] starts with '-' for
> > non-zero i.
> >
> > But do we really need to do that?
>
> No.
Exactly.
> > That means that the user has to specify something like
> >
> > HAHAHA_IT_IS_NOT=/plink.exe ssh
> >
> > as GIT_SSH_COMMAND.
>
> My second message was to clarify that "VAR1=VAL2 command" is NOT a
> contrived example, and this response indicates that I somehow failed
> to convey that to you.
Indeed. The quite contrived example was about a script that chooses
between plink and tortoiseplink (and fails to call anything else). And it
failed to convince me.
But since you seem to convinced that a future bug report like this may
happen (I am not, and it contradicts my conviction that one should cross a
bridge only when reaching it, but whatever), how about this, on top:
-- snipsnap --
diff --git a/connect.c b/connect.c
index c81f77001b..b990dd6190 100644
--- a/connect.c
+++ b/connect.c
@@ -797,7 +797,8 @@ struct child_process *git_connect(int fd[2], const
char *url,
char *split_ssh = xstrdup(ssh);
const char **ssh_argv;
- if (split_cmdline(split_ssh, &ssh_argv))
+ if (split_cmdline(split_ssh, &ssh_argv) &&
+ !strchr(ssh_argv[0], '='))
ssh_argv0 = xstrdup(ssh_argv[0]);
free(split_ssh);
free((void *)ssh_argv);
^ permalink raw reply related
* Re: [PATCH v3 14/21] read-cache: touch shared index files when used
From: Duy Nguyen @ 2017-01-09 10:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, git, Ævar Arnfjörð Bjarmason,
Christian Couder
In-Reply-To: <xmqqo9zi35n6.fsf@gitster.mtv.corp.google.com>
On Sun, Jan 8, 2017 at 4:46 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Christian Couder <christian.couder@gmail.com> writes:
>
>> So what should we do if freshen_file() returns 0 which means that the
>> freshening failed?
>
> You tell me ;-) as you are the one who is proposing this feature.
My answer is, we are not worse than freshening loose objects case
(especially since I took the idea from there). In both cases we
silently ignore utime() error (sha1_file.c does retry, but will do
nothing else if the retry fails). And errors in odb are much more
serious than index files. If we are to improve it, I think we should
do it inside check_and_freshen_file(), maybe with an optional flag to
silence it.
> Isn't a failure to freshen it a grave error? We are letting a
> base/shared index file that is known to be in-use go stale and
> eventually subject for garbage collection, and the user should be
> notified in some way before the actual GC happens that renders the
> index file unusable?
>
> What is the failure mode after such a premature GC happens? What
> does the end-user see? Can you try to (1) split the index (2)
> modify bunch of entries (3) remove the base/shared index with /bin/rm
> and then see how various Git commands fail? Do they fail gracefully?
>
> I am trying to gauge the seriousness of ignoring such an error here.
If we fail to refresh it and the file is old enough and gc happens,
any index file referenced to it are broken. Any commands that read the
index will die(). The best you could do is delete $GIT_DIR/index and
read-tree HEAD.
--
Duy
^ permalink raw reply
* Re: Preserve/Prune Old Pack Files
From: Jeff King @ 2017-01-09 10:55 UTC (permalink / raw)
To: Mike Hommey; +Cc: git
In-Reply-To: <20170109070119.lite2o7k3t2wuvtt@glandium.org>
On Mon, Jan 09, 2017 at 04:01:19PM +0900, Mike Hommey wrote:
> > That's _way_ more complicated than your problem, and as I said, I do not
> > have a finished solution. But it seems like they touch on a similar
> > concept (a post-delete holding area for objects). So I thought I'd
> > mention it in case if spurs any brilliance.
>
> Something that is kind-of in the same family of problems is the
> "loosening" or objects on repacks, before they can be pruned.
>
> When you have a large repository and do large rewrite operations
> (extreme case, a filter-branch on a multi-hundred-thousands commits),
> and you gc for the first time, git will possibly create a *lot* of loose
> objects, each of which will consume an inode and a file system block. In
> the extreme case, you can end up with git gc filling up multiple extra
> gigabytes on your disk.
I think we're getting pretty far off-field here. :)
Yes, this can be a problem. The repack is smart enough not to write out
objects which would just get pruned immediately, but since the grace
period is 2 weeks, that can include a lot of objects (especially with
history rewriting as you note). It would be possible to write those
loose objects to a "cruft" pack, but there are some management issues
around the cruft pack. You do not want to keep repacking them into a new
cruft pack at each repack, since then they would never expire. So you
need some way of marking the pack as cruft, letting it age out, and then
deleting it after the grace period expires.
I don't think it would be _that_ hard, but AFAIK nobody has ever made
patches.
-Peff
^ permalink raw reply
* Re: Test failures when Git is built with libpcre and grep is built without it
From: A. Wilcox @ 2017-01-09 10:51 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20170102065351.7ymrm77asjbghgdg@sigill.intra.peff.net>
[-- Attachment #1.1: Type: text/plain, Size: 2146 bytes --]
On 02/01/17 00:53, Jeff King wrote:
> On Sat, Dec 31, 2016 at 10:59:11PM -0600, A. Wilcox wrote:
>
>> I'm attempting to package Git for our new Linux distribution and
>> I have run in to a failure on our PowerPC builder while running
>> the test suite.
>>
>> The PowerPC builder runs a tiny version of grep(1) that was not
>> built with PCRE. As such, grep -P returns 2 and prints:
>>
>> grep: support for the -P option is not compiled into this -
>> --disable-perl-regexp binary
>>
>> However, our Git build *does* link against libpcre. This causes
>> a tests numbered 142 and 143 to fail in t7810-grep.sh.
>
> If we are using "grep -P" in our test suite, it should definitely
> be marked with a prerequisite that is independent of the LIBPCRE
> one.
>
> But I can't find any such place in our test suite. [snip] Can you
> show us the output of "./t7810-grep.sh -v -i"?
>
> -Peff
>
The output of this command was almost 1400 lines, so I attached the log.
Interestingly enough, you seem to be right. The failure is very
bizarre and has nothing to do with system /bin/grep:
test_must_fail: command succeeded: git grep -G -F -P -E a\x{2b}b\x{2a}c ab
not ok 142 - grep -G -F -P -E pattern
#
# >empty &&
# test_must_fail git grep -G -F -P -E "a\x{2b}b\x{2a}c"
ab >actual &&
# test_cmp empty actual
#
However:
elaine trash directory.t7810-grep # git grep -G -F -P -E
a\x{2b}b\x{2a}c ab >actual
fatal: command line, 'ax{2b}bx{2a}c': Invalid contents of {}
elaine trash directory.t7810-grep # echo $?
128
elaine trash directory.t7810-grep # cat actual
elaine trash directory.t7810-grep #
I can reliably reproduce this on our x86_64 builder as well. Note
that our distro is based on the musl libc, not glibc. The shell is:
GNU bash, version 4.3.48(1)-release (powerpc-foxkit-linux-musl)
lrwxrwxrwx 1 root root 4 Dec 29 10:43 /bin/sh -> /bin/bash
Any further assistance would be greatly appreciated; this one really
has me stumped.
Best,
-arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
http://adelielinux.org
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: test-failure.log --]
[-- Type: text/x-log; name="test-failure.log", Size: 42056 bytes --]
elaine t # ./t7810-grep.sh -v -i
Initialized empty Git repository in /usr/src/dev-vcs/git-2.7.3-r1/work/git-2.7.3/t/trash directory.t7810-grep/.git/
expecting success:
{
echo foo mmap bar
echo foo_mmap bar
echo foo_mmap bar mmap
echo foo mmap bar_mmap
echo foo_mmap bar mmap baz
} >file &&
{
echo Hello world
echo HeLLo world
echo Hello_world
echo HeLLo_world
} >hello_world &&
{
echo "a+b*c"
echo "a+bc"
echo "abc"
} >ab &&
echo vvv >v &&
echo ww w >w &&
echo x x xx x >x &&
echo y yy >y &&
echo zzz > z &&
mkdir t &&
echo test >t/t &&
echo vvv >t/v &&
mkdir t/a &&
echo vvv >t/a/v &&
{
echo "line without leading space1"
echo " line with leading space1"
echo " line with leading space2"
echo " line with leading space3"
echo "line without leading space2"
} >space &&
git add . &&
test_tick &&
git commit -m initial
[master (root-commit) cfd9fd5] initial
Author: A U Thor <author@example.com>
13 files changed, 32 insertions(+)
create mode 100644 ab
create mode 100644 file
create mode 100644 hello.c
create mode 100644 hello_world
create mode 100644 space
create mode 100644 t/a/v
create mode 100644 t/t
create mode 100644 t/v
create mode 100644 v
create mode 100644 w
create mode 100644 x
create mode 100644 y
create mode 100644 z
ok 1 - setup
expecting success:
test_must_fail git grep "("
fatal: unmatched parenthesis
ok 2 - grep should not segfault with a bad input
expecting success:
{
echo ${HC}file:1:foo mmap bar
echo ${HC}file:3:foo_mmap bar mmap
echo ${HC}file:4:foo mmap bar_mmap
echo ${HC}file:5:foo_mmap bar mmap baz
} >expected &&
git -c grep.linenumber=false grep -n -w -e mmap $H >actual &&
test_cmp expected actual
ok 3 - grep -w HEAD
expecting success:
{
echo ${HC}file:1:foo mmap bar
echo ${HC}file:3:foo_mmap bar mmap
echo ${HC}file:4:foo mmap bar_mmap
echo ${HC}file:5:foo_mmap bar mmap baz
} >expected &&
git -c grep.linenumber=true grep -w -e mmap $H >actual &&
test_cmp expected actual
ok 4 - grep -w HEAD
expecting success:
{
echo ${HC}file:foo mmap bar
echo ${HC}file:foo_mmap bar mmap
echo ${HC}file:foo mmap bar_mmap
echo ${HC}file:foo_mmap bar mmap baz
} >expected &&
git -c grep.linenumber=true grep --no-line-number -w -e mmap $H >actual &&
test_cmp expected actual
ok 5 - grep -w HEAD
expecting success:
: >expected &&
test_must_fail git grep -n -w -e "^w" $H >actual &&
test_cmp expected actual
ok 6 - grep -w HEAD (w)
expecting success:
{
echo ${HC}x:1:x x xx x
} >expected &&
git grep -n -w -e "x xx* x" $H >actual &&
test_cmp expected actual
ok 7 - grep -w HEAD (x)
expecting success:
{
echo ${HC}y:1:y yy
} >expected &&
git grep -n -w -e "^y" $H >actual &&
test_cmp expected actual
ok 8 - grep -w HEAD (y-1)
expecting success:
: >expected &&
if git grep -n -w -e "^y y" $H >actual
then
echo should not have matched
cat actual
false
else
test_cmp expected actual
fi
ok 9 - grep -w HEAD (y-2)
expecting success:
: >expected &&
if git grep -n -w -e "^z" $H >actual
then
echo should not have matched
cat actual
false
else
test_cmp expected actual
fi
ok 10 - grep -w HEAD (z)
expecting success:
echo "${HC}t/t:1:test" >expected &&
git grep -n -e test $H >actual &&
test_cmp expected actual
ok 11 - grep HEAD (t-1)
expecting success:
echo "${HC}t:1:test" >expected &&
(
cd t &&
git grep -n -e test $H
) >actual &&
test_cmp expected actual
ok 12 - grep HEAD (t-2)
expecting success:
echo "${HC}t/t:1:test" >expected &&
(
cd t &&
git grep --full-name -n -e test $H
) >actual &&
test_cmp expected actual
ok 13 - grep HEAD (t-3)
expecting success:
! git grep -c test $H | grep /dev/null
ok 14 - grep -c HEAD (no /dev/null)
expecting success:
{
echo ${HC}t/a/v:1:vvv
echo ${HC}t/v:1:vvv
echo ${HC}v:1:vvv
} >expected &&
git grep --max-depth -1 -n -e vvv $H >actual &&
test_cmp expected actual
ok 15 - grep --max-depth -1 HEAD
expecting success:
{
echo ${HC}v:1:vvv
} >expected &&
git grep --max-depth 0 -n -e vvv $H >actual &&
test_cmp expected actual
ok 16 - grep --max-depth 0 HEAD
expecting success:
{
echo ${HC}t/a/v:1:vvv
echo ${HC}t/v:1:vvv
echo ${HC}v:1:vvv
} >expected &&
git grep --max-depth 0 -n -e vvv $H -- "*" >actual &&
test_cmp expected actual
ok 17 - grep --max-depth 0 -- '*' HEAD
expecting success:
{
echo ${HC}t/v:1:vvv
echo ${HC}v:1:vvv
} >expected &&
git grep --max-depth 1 -n -e vvv $H >actual &&
test_cmp expected actual
ok 18 - grep --max-depth 1 HEAD
expecting success:
{
echo ${HC}t/v:1:vvv
} >expected &&
git grep --max-depth 0 -n -e vvv $H -- t >actual &&
test_cmp expected actual
ok 19 - grep --max-depth 0 -- t HEAD
expecting success:
{
echo ${HC}t/v:1:vvv
echo ${HC}v:1:vvv
} >expected &&
git grep --max-depth 0 -n -e vvv $H -- . t >actual &&
test_cmp expected actual
ok 20 - grep --max-depth 0 -- . t HEAD
expecting success:
{
echo ${HC}t/v:1:vvv
echo ${HC}v:1:vvv
} >expected &&
git grep --max-depth 0 -n -e vvv $H -- t . >actual &&
test_cmp expected actual
ok 21 - grep --max-depth 0 -- t . HEAD
expecting success:
echo "${HC}ab:a+bc" >expected &&
git -c grep.extendedRegexp=false grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 22 - grep HEAD with grep.extendedRegexp=false
expecting success:
echo "${HC}ab:abc" >expected &&
git -c grep.extendedRegexp=true grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 23 - grep HEAD with grep.extendedRegexp=true
expecting success:
echo "${HC}ab:a+bc" >expected &&
git -c grep.patterntype=basic grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 24 - grep HEAD with grep.patterntype=basic
expecting success:
echo "${HC}ab:abc" >expected &&
git -c grep.patterntype=extended grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 25 - grep HEAD with grep.patterntype=extended
expecting success:
echo "${HC}ab:a+b*c" >expected &&
git -c grep.patterntype=fixed grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 26 - grep HEAD with grep.patterntype=fixed
expecting success:
echo "${HC}ab:a+b*c" >expected &&
git -c grep.patterntype=perl grep "a\x{2b}b\x{2a}c" $H ab >actual &&
test_cmp expected actual
ok 27 - grep HEAD with grep.patterntype=perl
expecting success:
echo "${HC}ab:abc" >expected &&
git \
-c grep.patternType=default \
-c grep.extendedRegexp=true \
grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 28 - grep HEAD with grep.patternType=default and grep.extendedRegexp=true
expecting success:
echo "${HC}ab:abc" >expected &&
git \
-c grep.extendedRegexp=true \
-c grep.patternType=default \
grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 29 - grep HEAD with grep.extendedRegexp=true and grep.patternType=default
expecting success:
echo "${HC}ab:abc" >expected &&
git \
-c grep.patternType=extended \
-c grep.extendedRegexp=false \
grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 30 - grep HEAD with grep.patternType=extended and grep.extendedRegexp=false
expecting success:
echo "${HC}ab:a+bc" >expected &&
git \
-c grep.patternType=basic \
-c grep.extendedRegexp=true \
grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 31 - grep HEAD with grep.patternType=basic and grep.extendedRegexp=true
expecting success:
echo "${HC}ab:abc" >expected &&
git \
-c grep.extendedRegexp=false \
-c grep.patternType=extended \
grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 32 - grep HEAD with grep.extendedRegexp=false and grep.patternType=extended
expecting success:
echo "${HC}ab:a+bc" >expected &&
git \
-c grep.extendedRegexp=true \
-c grep.patternType=basic \
grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 33 - grep HEAD with grep.extendedRegexp=true and grep.patternType=basic
expecting success:
echo ${HC}ab:3 >expected &&
git grep --count -e b $H -- ab >actual &&
test_cmp expected actual
ok 34 - grep --count HEAD
expecting success:
echo 3 >expected &&
git grep --count -h -e b $H -- ab >actual &&
test_cmp expected actual
ok 35 - grep --count -h HEAD
expecting success:
{
echo ${HC}file:1:foo mmap bar
echo ${HC}file:3:foo_mmap bar mmap
echo ${HC}file:4:foo mmap bar_mmap
echo ${HC}file:5:foo_mmap bar mmap baz
} >expected &&
git -c grep.linenumber=false grep -n -w -e mmap $H >actual &&
test_cmp expected actual
ok 36 - grep -w in working tree
expecting success:
{
echo ${HC}file:1:foo mmap bar
echo ${HC}file:3:foo_mmap bar mmap
echo ${HC}file:4:foo mmap bar_mmap
echo ${HC}file:5:foo_mmap bar mmap baz
} >expected &&
git -c grep.linenumber=true grep -w -e mmap $H >actual &&
test_cmp expected actual
ok 37 - grep -w in working tree
expecting success:
{
echo ${HC}file:foo mmap bar
echo ${HC}file:foo_mmap bar mmap
echo ${HC}file:foo mmap bar_mmap
echo ${HC}file:foo_mmap bar mmap baz
} >expected &&
git -c grep.linenumber=true grep --no-line-number -w -e mmap $H >actual &&
test_cmp expected actual
ok 38 - grep -w in working tree
expecting success:
: >expected &&
test_must_fail git grep -n -w -e "^w" $H >actual &&
test_cmp expected actual
ok 39 - grep -w in working tree (w)
expecting success:
{
echo ${HC}x:1:x x xx x
} >expected &&
git grep -n -w -e "x xx* x" $H >actual &&
test_cmp expected actual
ok 40 - grep -w in working tree (x)
expecting success:
{
echo ${HC}y:1:y yy
} >expected &&
git grep -n -w -e "^y" $H >actual &&
test_cmp expected actual
ok 41 - grep -w in working tree (y-1)
expecting success:
: >expected &&
if git grep -n -w -e "^y y" $H >actual
then
echo should not have matched
cat actual
false
else
test_cmp expected actual
fi
ok 42 - grep -w in working tree (y-2)
expecting success:
: >expected &&
if git grep -n -w -e "^z" $H >actual
then
echo should not have matched
cat actual
false
else
test_cmp expected actual
fi
ok 43 - grep -w in working tree (z)
expecting success:
echo "${HC}t/t:1:test" >expected &&
git grep -n -e test $H >actual &&
test_cmp expected actual
ok 44 - grep in working tree (t-1)
expecting success:
echo "${HC}t:1:test" >expected &&
(
cd t &&
git grep -n -e test $H
) >actual &&
test_cmp expected actual
ok 45 - grep in working tree (t-2)
expecting success:
echo "${HC}t/t:1:test" >expected &&
(
cd t &&
git grep --full-name -n -e test $H
) >actual &&
test_cmp expected actual
ok 46 - grep in working tree (t-3)
expecting success:
! git grep -c test $H | grep /dev/null
ok 47 - grep -c in working tree (no /dev/null)
expecting success:
{
echo ${HC}t/a/v:1:vvv
echo ${HC}t/v:1:vvv
echo ${HC}v:1:vvv
} >expected &&
git grep --max-depth -1 -n -e vvv $H >actual &&
test_cmp expected actual
ok 48 - grep --max-depth -1 in working tree
expecting success:
{
echo ${HC}v:1:vvv
} >expected &&
git grep --max-depth 0 -n -e vvv $H >actual &&
test_cmp expected actual
ok 49 - grep --max-depth 0 in working tree
expecting success:
{
echo ${HC}t/a/v:1:vvv
echo ${HC}t/v:1:vvv
echo ${HC}v:1:vvv
} >expected &&
git grep --max-depth 0 -n -e vvv $H -- "*" >actual &&
test_cmp expected actual
ok 50 - grep --max-depth 0 -- '*' in working tree
expecting success:
{
echo ${HC}t/v:1:vvv
echo ${HC}v:1:vvv
} >expected &&
git grep --max-depth 1 -n -e vvv $H >actual &&
test_cmp expected actual
ok 51 - grep --max-depth 1 in working tree
expecting success:
{
echo ${HC}t/v:1:vvv
} >expected &&
git grep --max-depth 0 -n -e vvv $H -- t >actual &&
test_cmp expected actual
ok 52 - grep --max-depth 0 -- t in working tree
expecting success:
{
echo ${HC}t/v:1:vvv
echo ${HC}v:1:vvv
} >expected &&
git grep --max-depth 0 -n -e vvv $H -- . t >actual &&
test_cmp expected actual
ok 53 - grep --max-depth 0 -- . t in working tree
expecting success:
{
echo ${HC}t/v:1:vvv
echo ${HC}v:1:vvv
} >expected &&
git grep --max-depth 0 -n -e vvv $H -- t . >actual &&
test_cmp expected actual
ok 54 - grep --max-depth 0 -- t . in working tree
expecting success:
echo "${HC}ab:a+bc" >expected &&
git -c grep.extendedRegexp=false grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 55 - grep in working tree with grep.extendedRegexp=false
expecting success:
echo "${HC}ab:abc" >expected &&
git -c grep.extendedRegexp=true grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 56 - grep in working tree with grep.extendedRegexp=true
expecting success:
echo "${HC}ab:a+bc" >expected &&
git -c grep.patterntype=basic grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 57 - grep in working tree with grep.patterntype=basic
expecting success:
echo "${HC}ab:abc" >expected &&
git -c grep.patterntype=extended grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 58 - grep in working tree with grep.patterntype=extended
expecting success:
echo "${HC}ab:a+b*c" >expected &&
git -c grep.patterntype=fixed grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 59 - grep in working tree with grep.patterntype=fixed
expecting success:
echo "${HC}ab:a+b*c" >expected &&
git -c grep.patterntype=perl grep "a\x{2b}b\x{2a}c" $H ab >actual &&
test_cmp expected actual
ok 60 - grep in working tree with grep.patterntype=perl
expecting success:
echo "${HC}ab:abc" >expected &&
git \
-c grep.patternType=default \
-c grep.extendedRegexp=true \
grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 61 - grep in working tree with grep.patternType=default and grep.extendedRegexp=true
expecting success:
echo "${HC}ab:abc" >expected &&
git \
-c grep.extendedRegexp=true \
-c grep.patternType=default \
grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 62 - grep in working tree with grep.extendedRegexp=true and grep.patternType=default
expecting success:
echo "${HC}ab:abc" >expected &&
git \
-c grep.patternType=extended \
-c grep.extendedRegexp=false \
grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 63 - grep in working tree with grep.patternType=extended and grep.extendedRegexp=false
expecting success:
echo "${HC}ab:a+bc" >expected &&
git \
-c grep.patternType=basic \
-c grep.extendedRegexp=true \
grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 64 - grep in working tree with grep.patternType=basic and grep.extendedRegexp=true
expecting success:
echo "${HC}ab:abc" >expected &&
git \
-c grep.extendedRegexp=false \
-c grep.patternType=extended \
grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 65 - grep in working tree with grep.extendedRegexp=false and grep.patternType=extended
expecting success:
echo "${HC}ab:a+bc" >expected &&
git \
-c grep.extendedRegexp=true \
-c grep.patternType=basic \
grep "a+b*c" $H ab >actual &&
test_cmp expected actual
ok 66 - grep in working tree with grep.extendedRegexp=true and grep.patternType=basic
expecting success:
echo ${HC}ab:3 >expected &&
git grep --count -e b $H -- ab >actual &&
test_cmp expected actual
ok 67 - grep --count in working tree
expecting success:
echo 3 >expected &&
git grep --count -h -e b $H -- ab >actual &&
test_cmp expected actual
ok 68 - grep --count -h in working tree
expecting success:
git grep -l -C1 foo >actual &&
test_cmp expected actual
ok 69 - grep -l -C
expecting success:
git grep -c -C1 foo >actual &&
test_cmp expected actual
ok 70 - grep -l -C
expecting success:
git ls-files >expected &&
git grep -L -C1 nonexistent_string >actual &&
test_cmp expected actual
ok 71 - grep -L -C
expecting success:
git grep -e "foo mmap" --and -e bar_mmap >actual &&
test_cmp expected actual
ok 72 - grep -e A --and -e B
expecting success:
git grep \( -e foo_ --or -e baz \) \
--and -e " mmap" >actual &&
test_cmp expected actual
ok 73 - grep ( -e A --or -e B ) --and -e B
expecting success:
git grep -e "foo mmap" --and --not -e bar_mmap >actual &&
test_cmp expected actual
ok 74 - grep -e A --and --not -e B
expecting success:
GREP_OPTIONS=-v git grep " mmap bar\$" >actual &&
test_cmp expected actual
ok 75 - grep should ignore GREP_OPTIONS
expecting success:
test_must_fail git grep -f patterns
fatal: cannot open 'patterns': No such file or directory
ok 76 - grep -f, non-existent file
expecting success:
git grep -f pattern >actual &&
test_cmp expected actual
ok 77 - grep -f, one pattern
expecting success:
git grep -f patterns >actual &&
test_cmp expected actual
ok 78 - grep -f, multiple patterns
expecting success:
git grep "$(cat patterns)" >actual &&
test_cmp expected actual
ok 79 - grep, multiple patterns
expecting success:
git grep -f patterns >actual &&
test_cmp expected actual
ok 80 - grep -f, ignore empty lines
expecting success:
git grep -f - <patterns >actual &&
test_cmp expected actual
ok 81 - grep -f, ignore empty lines, read patterns from stdin
expecting success:
>empty &&
git grep -q mmap >actual &&
test_cmp empty actual &&
test_must_fail git grep -q qfwfq >actual &&
test_cmp empty actual
ok 82 - grep -q, silently report matches
expecting success:
git grep -C1 "^[yz]" >actual &&
test_cmp expected actual
ok 83 - grep -C1 hunk mark between files
expecting success:
echo a >>file &&
test_tick &&
GIT_AUTHOR_NAME="With * Asterisk" \
GIT_AUTHOR_EMAIL="xyzzy@frotz.com" \
git commit -a -m "second" &&
echo a >>file &&
test_tick &&
git commit -a -m "third" &&
echo a >>file &&
test_tick &&
GIT_AUTHOR_NAME="Night Fall" \
GIT_AUTHOR_EMAIL="nitfol@frobozz.com" \
git commit -a -m "fourth"
[master b39ecf0] second
Author: With * Asterisk <xyzzy@frotz.com>
1 file changed, 1 insertion(+)
[master 8f9afb5] third
Author: A U Thor <author@example.com>
1 file changed, 1 insertion(+)
[master 2d5652e] fourth
Author: Night Fall <nitfol@frobozz.com>
1 file changed, 1 insertion(+)
ok 84 - log grep setup
expecting success:
git log --author=author --pretty=tformat:%s >actual &&
{
echo third && echo initial
} >expect &&
test_cmp expect actual
ok 85 - log grep (1)
expecting success:
git log --author=" * " -F --pretty=tformat:%s >actual &&
{
echo second
} >expect &&
test_cmp expect actual
ok 86 - log grep (2)
expecting success:
git log --author="^A U" --pretty=tformat:%s >actual &&
{
echo third && echo initial
} >expect &&
test_cmp expect actual
ok 87 - log grep (3)
expecting success:
git log --author="frotz\.com>$" --pretty=tformat:%s >actual &&
{
echo second
} >expect &&
test_cmp expect actual
ok 88 - log grep (4)
expecting success:
git log --author=Thor -F --pretty=tformat:%s >actual &&
{
echo third && echo initial
} >expect &&
test_cmp expect actual
ok 89 - log grep (5)
expecting success:
git log --author=-0700 --pretty=tformat:%s >actual &&
>expect &&
test_cmp expect actual
ok 90 - log grep (6)
expecting success:
git log -g --grep-reflog="commit: third" --pretty=tformat:%s >actual &&
echo third >expect &&
test_cmp expect actual
ok 91 - log grep (7)
expecting success:
git log -g --grep-reflog="commit: third" --grep-reflog="commit: second" --pretty=tformat:%s >actual &&
{
echo third && echo second
} >expect &&
test_cmp expect actual
ok 92 - log grep (8)
expecting success:
git log -g --grep-reflog="commit: third" --author="Thor" --pretty=tformat:%s >actual &&
echo third >expect &&
test_cmp expect actual
ok 93 - log grep (9)
expecting success:
git log -g --grep-reflog="commit: third" --author="non-existant" --pretty=tformat:%s >actual &&
: >expect &&
test_cmp expect actual
ok 94 - log grep (9)
expecting success:
test_must_fail git log --grep-reflog="commit: third"
fatal: cannot use --grep-reflog without --walk-reflogs
ok 95 - log --grep-reflog can only be used under -g
expecting success:
git log --grep=i --grep=r --format=%s >actual &&
{
echo fourth && echo third && echo initial
} >expect &&
test_cmp expect actual
ok 96 - log with multiple --grep uses union
expecting success:
git log --all-match --grep=i --grep=r --format=%s >actual &&
{
echo third
} >expect &&
test_cmp expect actual
ok 97 - log --all-match with multiple --grep uses intersection
expecting success:
git log --author="Thor" --author="Aster" --format=%s >actual &&
{
echo third && echo second && echo initial
} >expect &&
test_cmp expect actual
ok 98 - log with multiple --author uses union
expecting success:
git log --all-match --author="Thor" --author="Aster" --format=%s >actual &&
{
echo third && echo second && echo initial
} >expect &&
test_cmp expect actual
ok 99 - log --all-match with multiple --author still uses union
expecting success:
# grep matches only third and fourth
# author matches only initial and third
git log --author="A U Thor" --grep=r --format=%s >actual &&
{
echo third
} >expect &&
test_cmp expect actual
ok 100 - log --grep --author uses intersection
expecting success:
# grep matches initial and second but not third
# author matches only initial and third
git log --author="A U Thor" --grep=s --grep=l --format=%s >actual &&
{
echo initial
} >expect &&
test_cmp expect actual
ok 101 - log --grep --grep --author takes union of greps and intersects with author
expecting success:
# grep matches only initial and third
# author matches all but second
git log --all-match --author="Thor" --author="Night" --grep=i --format=%s >actual &&
{
echo third && echo initial
} >expect &&
test_cmp expect actual
ok 102 - log ---all-match -grep --author --author still takes union of authors and intersects with grep
expecting success:
# grep matches only initial and third
# author matches all but second
git log --author="Thor" --author="Night" --grep=i --format=%s >actual &&
{
echo third && echo initial
} >expect &&
test_cmp expect actual
ok 103 - log --grep --author --author takes union of authors and intersects with grep
expecting success:
# grep matches only third
# author matches only initial and third
git log --all-match --author="A U Thor" --grep=i --grep=r --format=%s >actual &&
{
echo third
} >expect &&
test_cmp expect actual
ok 104 - log --all-match --grep --grep --author takes intersection
expecting success:
: >expect &&
git log --author="$GIT_AUTHOR_DATE" >actual &&
test_cmp expect actual
ok 105 - log --author does not search in timestamp
expecting success:
: >expect &&
git log --committer="$GIT_COMMITTER_DATE" >actual &&
test_cmp expect actual
ok 106 - log --committer does not search in timestamp
expecting success:
git update-index --assume-unchanged t/t &&
rm t/t &&
test "$(git grep test)" = "t/t:test" &&
git update-index --no-assume-unchanged t/t &&
git checkout t/t
ok 107 - grep with CE_VALID file
expecting success:
git config diff.custom.funcname "^#" &&
echo "hello.c diff=custom" >.gitattributes &&
git grep -p return >actual &&
test_cmp expected actual
ok 108 - grep -p with userdiff
expecting success:
rm -f .gitattributes &&
git grep -p return >actual &&
test_cmp expected actual
ok 109 - grep -p
expecting success:
git grep -p -B5 return >actual &&
test_cmp expected actual
ok 110 - grep -p -B5
expecting success:
git grep -W return >actual &&
test_cmp expected actual
ok 111 - grep -W
expecting success:
test_when_finished "rm -f .gitattributes" &&
git config diff.custom.xfuncname "(printf.*|})$" &&
echo "hello.c diff=custom" >.gitattributes &&
git grep -W return >actual &&
test_cmp expected actual
ok 112 - grep -W with userdiff
expecting success:
mkdir -p s &&
(
cd s && git grep "x x x" ..
)
../x:x x xx x
ok 113 - grep from a subdirectory to search wider area (1)
expecting success:
mkdir -p s &&
(
cd s || exit 1
( git grep xxyyzz .. >out ; echo $? >status )
! test -s out &&
test 1 = $(cat status)
)
ok 114 - grep from a subdirectory to search wider area (2)
expecting success:
git grep -Fi "CHAR *" >actual &&
test_cmp expected actual
ok 115 - grep -Fi
expecting success:
rm -fr non &&
mkdir -p non/git/sub &&
echo hello >non/git/file1 &&
echo world >non/git/sub/file2 &&
{
echo file1:hello &&
echo sub/file2:world
} >non/expect.full &&
echo file2:world >non/expect.sub &&
(
GIT_CEILING_DIRECTORIES="$(pwd)/non/git" &&
export GIT_CEILING_DIRECTORIES &&
cd non/git &&
test_must_fail git grep o &&
git grep --no-index o >../actual.full &&
test_cmp ../expect.full ../actual.full
cd sub &&
test_must_fail git grep o &&
git grep --no-index o >../../actual.sub &&
test_cmp ../../expect.sub ../../actual.sub
) &&
echo ".*o*" >non/git/.gitignore &&
(
GIT_CEILING_DIRECTORIES="$(pwd)/non/git" &&
export GIT_CEILING_DIRECTORIES &&
cd non/git &&
test_must_fail git grep o &&
git grep --no-index --exclude-standard o >../actual.full &&
test_cmp ../expect.full ../actual.full &&
{
echo ".gitignore:.*o*"
cat ../expect.full
} >../expect.with.ignored &&
git grep --no-index --no-exclude o >../actual.full &&
test_cmp ../expect.with.ignored ../actual.full
)
fatal: Not a git repository (or any of the parent directories): .git
ok 116 - outside of git repository
expecting success:
rm -fr is &&
mkdir -p is/git/sub &&
echo hello >is/git/file1 &&
echo world >is/git/sub/file2 &&
echo ".*o*" >is/git/.gitignore &&
{
echo file1:hello &&
echo sub/file2:world
} >is/expect.unignored &&
{
echo ".gitignore:.*o*" &&
cat is/expect.unignored
} >is/expect.full &&
: >is/expect.empty &&
echo file2:world >is/expect.sub &&
(
cd is/git &&
git init &&
test_must_fail git grep o >../actual.full &&
test_cmp ../expect.empty ../actual.full &&
git grep --untracked o >../actual.unignored &&
test_cmp ../expect.unignored ../actual.unignored &&
git grep --no-index o >../actual.full &&
test_cmp ../expect.full ../actual.full &&
git grep --no-index --exclude-standard o >../actual.unignored &&
test_cmp ../expect.unignored ../actual.unignored &&
cd sub &&
test_must_fail git grep o >../../actual.sub &&
test_cmp ../../expect.empty ../../actual.sub &&
git grep --no-index o >../../actual.sub &&
test_cmp ../../expect.sub ../../actual.sub &&
git grep --untracked o >../../actual.sub &&
test_cmp ../../expect.sub ../../actual.sub
)
Initialized empty Git repository in /usr/src/dev-vcs/git-2.7.3-r1/work/git-2.7.3/t/trash directory.t7810-grep/is/git/.git/
ok 117 - inside git repository but with --no-index
expecting success:
cat >double-dash <<EOF &&
--
->
other
EOF
git add double-dash
ok 118 - setup double-dash tests
expecting success:
git grep -- "->" >actual &&
test_cmp expected actual
ok 119 - grep -- pattern
expecting success:
git grep -- "->" -- double-dash >actual &&
test_cmp expected actual
ok 120 - grep -- pattern -- pathspec
expecting success:
git grep -e "->" -- double-dash >actual &&
test_cmp expected actual
ok 121 - grep -e pattern -- path
expecting success:
git grep -e -- -- double-dash >actual &&
test_cmp expected actual
ok 122 - grep -e -- -- path
expecting success:
git grep --perl-regexp "\p{Ps}.*?\p{Pe}" hello.c >actual &&
test_cmp expected actual
ok 123 - grep --perl-regexp pattern
expecting success:
git grep -P "\p{Ps}.*?\p{Pe}" hello.c >actual &&
test_cmp expected actual
ok 124 - grep -P pattern
expecting success:
>empty &&
test_must_fail git -c grep.extendedregexp=true \
grep "\p{Ps}.*?\p{Pe}" hello.c >actual &&
test_cmp empty actual
fatal: command line, '\p{Ps}.*?\p{Pe}': Invalid contents of {}
ok 125 - grep pattern with grep.extendedRegexp=true
expecting success:
git -c grep.extendedregexp=true \
grep -P "\p{Ps}.*?\p{Pe}" hello.c >actual &&
test_cmp expected actual
ok 126 - grep -P pattern with grep.extendedRegexp=true
expecting success:
{
echo "ab:a+b*c"
echo "ab:a+bc"
} >expected &&
git grep -P -v "abc" ab >actual &&
test_cmp expected actual
ok 127 - grep -P -v pattern
expecting success:
cat >expected <<-EOF &&
hello.c: printf("Hello world.\n");
EOF
git grep -P -i "PRINTF\([^\d]+\)" hello.c >actual &&
test_cmp expected actual
ok 128 - grep -P -i pattern
expecting success:
{
echo "hello_world:Hello world"
echo "hello_world:HeLLo world"
} >expected &&
git grep -P -w "He((?i)ll)o" hello_world >actual &&
test_cmp expected actual
ok 129 - grep -P -w pattern
expecting success:
test_must_fail git grep -G "a["
fatal: command line, 'a[': Missing ']'
ok 130 - grep -G invalidpattern properly dies
expecting success:
test_must_fail git -c grep.patterntype=basic grep "a["
fatal: command line, 'a[': Missing ']'
ok 131 - grep invalidpattern properly dies with grep.patternType=basic
expecting success:
test_must_fail git grep -E "a["
fatal: command line, 'a[': Missing ']'
ok 132 - grep -E invalidpattern properly dies
expecting success:
test_must_fail git -c grep.patterntype=extended grep "a["
fatal: command line, 'a[': Missing ']'
ok 133 - grep invalidpattern properly dies with grep.patternType=extended
expecting success:
test_must_fail git grep -P "a["
fatal: command line, 'a[': missing terminating ] for character class
ok 134 - grep -P invalidpattern properly dies
expecting success:
test_must_fail git -c grep.patterntype=perl grep "a["
fatal: command line, 'a[': missing terminating ] for character class
ok 135 - grep invalidpattern properly dies with grep.patternType=perl
expecting success:
echo "ab:a+b*c" >expected &&
git grep -G -E -F "a+b*c" ab >actual &&
test_cmp expected actual
ok 136 - grep -G -E -F pattern
expecting success:
echo "ab:a+b*c" >expected &&
git \
-c grep.patterntype=basic \
-c grep.patterntype=extended \
-c grep.patterntype=fixed \
grep "a+b*c" ab >actual &&
test_cmp expected actual
ok 137 - grep pattern with grep.patternType=basic, =extended, =fixed
expecting success:
echo "ab:a+bc" >expected &&
git grep -E -F -G "a+b*c" ab >actual &&
test_cmp expected actual
ok 138 - grep -E -F -G pattern
expecting success:
echo "ab:a+bc" >expected &&
git \
-c grep.patterntype=extended \
-c grep.patterntype=fixed \
-c grep.patterntype=basic \
grep "a+b*c" ab >actual &&
test_cmp expected actual
ok 139 - grep pattern with grep.patternType=extended, =fixed, =basic
expecting success:
echo "ab:abc" >expected &&
git grep -F -G -E "a+b*c" ab >actual &&
test_cmp expected actual
ok 140 - grep -F -G -E pattern
expecting success:
echo "ab:abc" >expected &&
git \
-c grep.patterntype=fixed \
-c grep.patterntype=basic \
-c grep.patterntype=extended \
grep "a+b*c" ab >actual &&
test_cmp expected actual
ok 141 - grep pattern with grep.patternType=fixed, =basic, =extended
expecting success:
>empty &&
test_must_fail git grep -G -F -P -E "a\x{2b}b\x{2a}c" ab >actual &&
test_cmp empty actual
test_must_fail: command succeeded: git grep -G -F -P -E a\x{2b}b\x{2a}c ab
not ok 142 - grep -G -F -P -E pattern
#
# >empty &&
# test_must_fail git grep -G -F -P -E "a\x{2b}b\x{2a}c" ab >actual &&
# test_cmp empty actual
#
elaine t # elaine t # cd trash\ directory.t7810-grep/
elaine trash directory.t7810-grep # git grep -G -F -P -E a\x{2b}b\x{2a}c ab >actual
fatal: command line, 'ax{2b}bx{2a}c': Invalid contents of {}
elaine trash directory.t7810-grep # echo $?
128
elaine trash directory.t7810-grep # cat actual
elaine trash directory.t7810-grep # rm actual
elaine trash directory.t7810-grep #
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] Makefile: put LIBS after LDFLAGS for imap-send
From: Johannes Schindelin @ 2017-01-09 10:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Penny, git
In-Reply-To: <xmqqy3ylx75g.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Sun, 8 Jan 2017, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Sun, 8 Jan 2017, Steven Penny wrote:
> >
> >> On Sun, Jan 8, 2017 at 5:54 AM, Johannes Schindelin wrote:
> >> > I am curious: how do you build Git? I ask because I build Git on
> >> > Windows many times a day, and I did not encounter any link
> >> > problems.
> >>
> >> My end goal is to build static native Windows Git via Cygwin and the
> >> mingw64-x86_64-gcc-core package.
> >
> > That is certainly a worthy goal, and I would highly recommend to
> > mention that particular cross-compiling setup in the commit message.
> > It's not like this is the easiest way to build native Git on
> > Windows...
>
> In addition to the patch being explained well, I also care that it
> does not break existing builds. I do not think it is the case for
> you, and I do think the patch does the right thing, but just double
> checking to see if you have objections to the change itself.
I just double-checked and it still builds fine on Git for Windows (as
expected).
The reason it seems to have worked before, too, is that somehow -lcrypto
does not require gdi32.dll here. As a matter of fact, we do not link with
gdi32 at all:
$ printf 'include Makefile\nprint:\n\t@%s\n\t@%s\n\t@%s\n' \
'echo all: $(ALL_LDFLAGS)' \
'echo libs: $(LIBS)' \
'echo imap: $(IMAP_SEND_LDFLAGS)' |
make -f - print
all: -Wl,--nxcompat -Wl,--dynamicbase -Wl,--pic-executable,-e,mainCRTStartup
libs: libgit.a xdiff/lib.a git.res -lws2_32 -lntdll -lpcre -lz -liconv -lintl -lcrypto
imap: -lcurl -lssl -lcrypto -lcrypto
It is a bit curious that -lws2_32 *does* only show up in $(LIBS), but I
guess it is simply the fact that we use a newer GCC (gcc.exe (Rev2, Built
by MSYS2 project) 6.2.0) that allows Git for Windows to be built even
without this patch.
In any case, it does not break things, and it helps Cygwin, so: ACK
Ciao,
Dscho
P.S.: I pushed this to Git for Windows' `master`, too:
https://github.com/git-for-windows/git/commit/f05a26948b
^ permalink raw reply
* [PATCH v4] log --graph: customize the graph lines with config log.graphColors
From: Nguyễn Thái Ngọc Duy @ 2017-01-09 10:32 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Jeff King, Nguyễn Thái Ngọc Duy
In-Reply-To: <20170108101333.26221-1-pclouds@gmail.com>
If you have a 256 colors terminal (or one with true color support), then
the predefined 12 colors seem limited. On the other hand, you don't want
to draw graph lines with every single color in this mode because the two
colors could look extremely similar. This option allows you to hand pick
the colors you want.
Even with standard terminal, if your background color is neither black
or white, then the graph line may match your background and become
hidden. You can exclude your background color (or simply the colors you
hate) with this.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
v4:
* rename the function again (and it reads better)
* use argv_array
* fix a bug with two consecutive commas (after spaces are trimmed)
Documentation/config.txt | 4 ++++
graph.c | 43 +++++++++++++++++++++++++++++++++++++++++--
t/t4202-log.sh | 22 ++++++++++++++++++++++
3 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0bcb679..33a007b 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2003,6 +2003,10 @@ log.follow::
i.e. it cannot be used to follow multiple files and does not work well
on non-linear history.
+log.graphColors::
+ A list of colors, separated by commas, that can be used to draw
+ history lines in `git log --graph`.
+
log.showRoot::
If true, the initial commit will be shown as a big creation event.
This is equivalent to a diff against an empty tree.
diff --git a/graph.c b/graph.c
index dd17201..83b1d42 100644
--- a/graph.c
+++ b/graph.c
@@ -4,6 +4,7 @@
#include "graph.h"
#include "diff.h"
#include "revision.h"
+#include "argv-array.h"
/* Internal API */
@@ -62,6 +63,45 @@ enum graph_state {
static const char **column_colors;
static unsigned short column_colors_max;
+static void read_graph_colors_config(void)
+{
+ static struct argv_array colors = ARGV_ARRAY_INIT;
+ char *string = NULL;
+ const char *end, *start;
+
+ if (git_config_get_string("log.graphcolors", &string)) {
+ graph_set_column_colors(column_colors_ansi,
+ column_colors_ansi_max);
+ return;
+ }
+
+ argv_array_clear(&colors);
+ start = string;
+ end = string + strlen(string);
+ while (start < end) {
+ const char *comma = strchrnul(start, ',');
+ char color[COLOR_MAXLEN];
+
+ while (start < comma && isspace(*start))
+ start++;
+ if (start == comma) {
+ start = comma + 1;
+ continue;
+ }
+
+ if (!color_parse_mem(start, comma - start, color))
+ argv_array_push(&colors, color);
+ else
+ warning(_("ignore invalid color '%.*s' in log.graphColors"),
+ (int)(comma - start), start);
+ start = comma + 1;
+ }
+ free(string);
+ argv_array_push(&colors, GIT_COLOR_RESET);
+ /* graph_set_column_colors takes a max-index, not a count */
+ graph_set_column_colors(colors.argv, colors.argc - 1);
+}
+
void graph_set_column_colors(const char **colors, unsigned short colors_max)
{
column_colors = colors;
@@ -208,8 +248,7 @@ struct git_graph *graph_init(struct rev_info *opt)
struct git_graph *graph = xmalloc(sizeof(struct git_graph));
if (!column_colors)
- graph_set_column_colors(column_colors_ansi,
- column_colors_ansi_max);
+ read_graph_colors_config();
graph->commit = NULL;
graph->revs = opt;
diff --git a/t/t4202-log.sh b/t/t4202-log.sh
index e2db47c..0aeabed 100755
--- a/t/t4202-log.sh
+++ b/t/t4202-log.sh
@@ -313,6 +313,28 @@ test_expect_success 'log --graph with merge' '
test_cmp expect actual
'
+cat > expect.colors <<\EOF
+* Merge branch 'side'
+<BLUE>|<RESET><CYAN>\<RESET>
+<BLUE>|<RESET> * side-2
+<BLUE>|<RESET> * side-1
+* <CYAN>|<RESET> Second
+* <CYAN>|<RESET> sixth
+* <CYAN>|<RESET> fifth
+* <CYAN>|<RESET> fourth
+<CYAN>|<RESET><CYAN>/<RESET>
+* third
+* second
+* initial
+EOF
+
+test_expect_success 'log --graph with merge with log.graphColors' '
+ test_config log.graphColors ",, blue,invalid-color, cyan, red , " &&
+ git log --color=always --graph --date-order --pretty=tformat:%s |
+ test_decode_color | sed "s/ *\$//" >actual &&
+ test_cmp expect.colors actual
+'
+
test_expect_success 'log --raw --graph -m with merge' '
git log --raw --graph --oneline -m master | head -n 500 >actual &&
grep "initial" actual
--
2.8.2.524.g6ff3d78
^ permalink raw reply related
* Re: [PATCH] branch_get_push: do not segfault when HEAD is detached
From: Junio C Hamano @ 2017-01-09 10:32 UTC (permalink / raw)
To: Jeff King; +Cc: Kyle Meyer, Johannes Schindelin, git
In-Reply-To: <20170107013126.4ub726mf73y36of3@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Jan 06, 2017 at 08:19:53PM -0500, Kyle Meyer wrote:
>
>> > The other option is just "git checkout --detach", which is also used in
>> > the test suite. I tend to prefer it because it's a little more obvious
>> > to a reader.
>>
>> True, that does seem clearer. Seems I should've waited a bit before
>> sending out v2.
>
> I think it's OK either way. Junio can also mark it up while applying,
> too, if he has a preference.
I prefer <commit>^0 in scripts, simply because it is shorter, works
with any version of Git that knows how to detach, even the ones
before --detach was introduced. I offhand do not recall which
between <commit>^0 and <commit>^{} came earlier, but in practice I
saw nobody write the latter, so Dscho's suggestion is definitely an
improvement.
I do also care about "git checkout --detach" to keep working
correctly, but as long as we have dedicated tests to ensure that,
we'd be fine. In the case of the test being discussed, we assume
either should work correctly and the point of the test is not about
ensuring that <commit>^0 or --detach works, so either is OK.
Anyway, thanks for a patch and a review.
^ permalink raw reply
* Re: [PATCH v3] log --graph: customize the graph lines with config log.graphColors
From: Duy Nguyen @ 2017-01-09 10:30 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20170109053047.sn75d6ynipgf4nur@sigill.intra.peff.net>
On Mon, Jan 9, 2017 at 12:30 PM, Jeff King <peff@peff.net> wrote:
> I also wonder if it is worth just using argv_array. We do not care about
> NULL-terminating the list here, but it actually works pretty well as a
> generic string-array class (and keeping a NULL at the end of any
> array-of-pointers is a reasonable defensive measure). Then the function
> becomes:
>
> argv_array_clear(&colors);
> ...
> if (!color_parse_mem(..., color))
> argv_array_push(&colors, color);
> ...
> argv_array_push(&colors, GIT_COLOR_RESET);
> /* graph_set_column_colors takes a max-index, not a count */
> graph_set_column_colors(colors.argv, colors.argc - 1);
>
> It is not much shorter than ALLOC_GROW(), but IMHO it is easier to read.
Indeed. My only complaint is it's "argv_array_" and not
"string_array_" but we could think about renaming it later when we see
another use like this.
--
Duy
^ permalink raw reply
* Re: [PATCH v3] log --graph: customize the graph lines with config log.graphColors
From: Duy Nguyen @ 2017-01-09 10:10 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20170109053446.2vg3y37ck5ahhyxg@sigill.intra.peff.net>
On Mon, Jan 9, 2017 at 12:34 PM, Jeff King <peff@peff.net> wrote:
>> +test_expect_success 'log --graph with merge with log.graphColors' '
>> + test_config log.graphColors " blue , cyan , red " &&
>
> This funny syntax isn't required, right? It should work with the more
> natural:
>
> test_config log.graphColors "blue, cyan, red"
Yeah spaces are optional. I just wanted to put extra spaces there
because I hit a bug with them.
--
Duy
^ permalink raw reply
* Re: git branch -D doesn't work with deleted worktree
From: Duy Nguyen @ 2017-01-09 10:07 UTC (permalink / raw)
To: Jacob Keller; +Cc: Stefan Beller, Roland Illig, git@vger.kernel.org
In-Reply-To: <CA+P7+xofFufcUMBJFqEcP=C5r80HCr1-j4210gOm7t=aLYw2zw@mail.gmail.com>
On Mon, Jan 9, 2017 at 10:44 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
> Why not just update the documentation to be "when you are done with a
> work tree you can delete it and then run git worktree prune"?
The document does say that (a bit verbose though):
When you are done with a linked working tree you can simply delete it.
The working tree's administrative files in the repository (see
"DETAILS" below) will eventually be removed automatically (see
`gc.worktreePruneExpire` in linkgit:git-config[1]), or you can run
`git worktree prune` in the main or any linked working tree to
clean up any stale administrative files.
--
Duy
^ permalink raw reply
* Re: [PATCH v4 2/2] t9813: avoid using pipes
From: Junio C Hamano @ 2017-01-09 9:54 UTC (permalink / raw)
To: Luke Diamand; +Cc: Pranit Bauva, Git Users
In-Reply-To: <CAE5ih7-mAfezTwdbWrAWFOSoCf-z_NJOic+FQdCmHbCyR8ng9w@mail.gmail.com>
Luke Diamand <luke@diamand.org> writes:
> On 8 January 2017 at 16:55, Pranit Bauva <pranit.bauva@gmail.com> wrote:
>> The exit code of the upstream in a pipe is ignored thus we should avoid
>> using it. By writing out the output of the git command to a file, we can
>> test the exit codes of both the commands.
>
> Looks good to me, thanks!
>
> Ack.
Thanks, both.
^ permalink raw reply
* Re: [PATCH] Makefile: POSIX windres
From: Junio C Hamano @ 2017-01-09 9:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Penny, Johannes Sixt, git
In-Reply-To: <alpine.DEB.2.20.1701090903500.3469@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> Who other than cygwin build uses this target? Git for Windows?
>
> Yes, Git for Windows uses this target, as did msysGit (and I suspect
> Hannes' setup).
> ...
> So: ACK
Thanks.
^ permalink raw reply
* Re: [PATCH v4 4/4] t7800: run both builtin and scripted difftool, for now
From: Junio C Hamano @ 2017-01-09 9:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, David Aguilar, Dennis Kaarsemaker, Paul Sbarra
In-Reply-To: <alpine.DEB.2.20.1701090850340.3469@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> And the most important point is that we do all of this only during a
> hopefully brief period in time that is mostly spent on reviewing the code
> and finding serious bugs and fixing them.
You seem to misunderstand the purpose of the code review.
We indeed spot bugs while reviewing patches, especially ones from
less experienced folks, but that is the least important part of the
review. In general, we review for:
- Design. Is the feature make sense? Is it too narrow? Are there
better ways? Does it fit well with the rest of the system?
- Explanation. Is the purpose of the change in the bigger picture
explained well enough to allow future people to answer this
question: "We now have an additional requirement to the feature.
If the original author knew about that when this was first
introduced, would s/he consider that our design for this
additional thing consistent with the original design? Should we
design our enhancement in a different way?"
- Maintainability. Does the implementation avoid reinventing data
structures and helper functions that already exist to interact
with elements in the system? Would a future change to some
elements in the system that are touched by the implementation
require changes to both existing code _and_ reinvented ones the
patch introduced?
- Correctness. Does the implementation actually reflect the design
and the way the design was explained?
For the "difftool in C" topic, the first two are mostly irrelevant
as the goal of the topic is to first replicate what already exists
faithfully (even in a bug-to-bug compatible way). The issues in
correctness is something your daily use before submission would
have caught, use of 'next' users as testers will help, and also
caught by running test suite (again, before submission).
I honestly do not expect glaring errors in the code from experienced
contributors remaining when their patches are polished enough to be
submit to the list.
^ permalink raw reply
* Re: [PATCH] connect: handle putty/plink also in GIT_SSH_COMMAND
From: Junio C Hamano @ 2017-01-09 9:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Segev Finer
In-Reply-To: <alpine.DEB.2.20.1701090825510.3469@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> If you feel strongly about your contrived examples possibly being
> affected by this patch, we could easily make this conditional on
>
> 1) no '&&' or '||' being found on the command-line, and
> 2) argv[0] not containing an '='
>
> Another approach would be to verify that argv[i] starts with '-' for
> non-zero i.
>
> But do we really need to do that?
No. An explicit way to override an incorrect guess is sufficient
and necessary. The above two-item list you gave will be just part
of the machinery to make an incorrect guess. The auto-detection in
the posted patch should cover many users' use case and I do not
think it needs to be extended further to make it more brittle, as by
definition its guess cannot be perfect. Just keep it simple and
give a separate escape hatch.
> That means that the user has to specify something like
>
> HAHAHA_IT_IS_NOT=/plink.exe ssh
>
> as GIT_SSH_COMMAND.
My second message was to clarify that "VAR1=VAL2 command" is NOT a
contrived example, and this response indicates that I somehow failed
to convey that to you. The "if tortoiseplink exists (and the end
user can override the location with an environment), use that, and
if PuTTY plink exists (ditto), use that instead" in a "myssh"
script, and use it as core.sshcommand with the environment to
override my custom installation location to these two programs,
would be what I would do when I get two Windows machines, with these
variants of SSH on each. So take the second message as a bug report
against the version of Git for Windows you ship with the patch in
question.
The auto-detection may work for many people and that is a great
thing. I failed to say that in my message, as I thought that was
obvious. But it is important to plan to cope with the case where it
does not work. The usual practice around here is to say "the it may
not necessarily work for everybody, so lets be prepared to add an
explicit override if it turns out to be necessary".
The second message, which you are responding to, was meant to be a
bug report from the future, telling us that an override is needed,
showing that we do not have to wait for a bug report to act on.
^ permalink raw reply
* Re: [PATCH v4 2/2] t9813: avoid using pipes
From: Luke Diamand @ 2017-01-09 9:11 UTC (permalink / raw)
To: Pranit Bauva; +Cc: Git Users
In-Reply-To: <010201597f0179fb-fc4c0240-5ec7-466b-96b9-59f4840954d7-000000@eu-west-1.amazonses.com>
On 8 January 2017 at 16:55, Pranit Bauva <pranit.bauva@gmail.com> wrote:
> The exit code of the upstream in a pipe is ignored thus we should avoid
> using it. By writing out the output of the git command to a file, we can
> test the exit codes of both the commands.
Looks good to me, thanks!
Ack.
>
> Signed-off-by: Pranit Bauva <pranit.bauva@gmail.com>
> ---
> t/t9813-git-p4-preserve-users.sh | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/t/t9813-git-p4-preserve-users.sh b/t/t9813-git-p4-preserve-users.sh
> index 76004a5..bda222a 100755
> --- a/t/t9813-git-p4-preserve-users.sh
> +++ b/t/t9813-git-p4-preserve-users.sh
> @@ -118,12 +118,12 @@ test_expect_success 'not preserving user with mixed authorship' '
> make_change_by_user usernamefile3 Derek derek@example.com &&
> P4EDITOR=cat P4USER=alice P4PASSWD=secret &&
> export P4EDITOR P4USER P4PASSWD &&
> - git p4 commit |\
> - grep "git author derek@example.com does not match" &&
> + git p4 commit >actual &&
> + grep "git author derek@example.com does not match" actual &&
>
> make_change_by_user usernamefile3 Charlie charlie@example.com &&
> - git p4 commit |\
> - grep "git author charlie@example.com does not match" &&
> + git p4 commit >actual &&
> + grep "git author charlie@example.com does not match" actual &&
>
> make_change_by_user usernamefile3 alice alice@example.com &&
> git p4 commit >actual &&
>
> --
> https://github.com/git/git/pull/314
^ permalink raw reply
* [PATCH 2/2] completion: add bash completion for 'filter-branch'
From: Denton Liu @ 2017-01-09 8:56 UTC (permalink / raw)
To: git; +Cc: spearce
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
contrib/completion/git-completion.bash | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 51832108e..b4cbea5c7 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1297,6 +1297,23 @@ _git_fetch ()
__git_complete_remote_or_refspec
}
+__git_filter_branch_options="
+ --env-filter --tree-filter --index-filter --parent-filter --msg-filter
+ --commit-filter --tag-name-filter --subdirectory-filter --prune-empty
+ --original --force
+"
+_git_filter_branch ()
+{
+ __git_has_doubledash && __git_complete_rev_list_command && return
+
+ case "$cur" in
+ --*)
+ __gitcomp "$__git_filter_branch_options"
+ return
+ ;;
+ esac
+}
+
__git_format_patch_options="
--stdout --attach --no-attach --thread --thread= --no-thread
--numbered --start-number --numbered-files --keep-subject --signoff
--
2.11.0
^ permalink raw reply related
* [PATCH 1/2] completion: add bash completion for 'git rev-list'
From: Denton Liu @ 2017-01-09 8:56 UTC (permalink / raw)
To: git; +Cc: spearce
Signed-off-by: Denton Liu <liu.denton@gmail.com>
---
contrib/completion/git-completion.bash | 30 ++++++++++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 21016bf8d..51832108e 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -2430,6 +2430,36 @@ _git_revert ()
__gitcomp_nl "$(__git_refs)"
}
+__git_rev_list_options="
+ --max-count= --skip= --max-age= --min-age= --sparse --merges --no-merges
+ --min-parents= --no-min-parents --max-parents= --no-max-parents --first-parent
+ --remove-empty --full-history --not --all --branches= --tags= --remotes=
+ --glob= --ignore-missing --stdin --quiet --topo-order --parents --timestamp
+ --left-right --left-only --right-only --cherry-mark --cherry-pick --encoding=
+ --author= --committer= --grep= --regexp-ignore-case --extended-regexp
+ --fixed-strings --date= --objects --objects-edge --objects-edge-aggressive
+ --unpacked --pretty --header --bisect --bisect-vars --bisect-all --merge
+ --reverse --walk-reflogs --no-walk --do-walk --count --use-bitmap-index
+"
+
+__git_complete_rev_list_command ()
+{
+ case "$cur" in
+ --*)
+ __gitcomp "$__git_rev_list_options"
+ return 0
+ ;;
+ esac
+ return 1
+}
+
+_git_rev_list ()
+{
+ __git_has_doubledash && return
+
+ __git_complete_rev_list_command || __gitcomp_nl "$(__git_refs)"
+}
+
_git_rm ()
{
case "$cur" in
--
2.11.0
^ permalink raw reply related
* Re: [PATCH] Makefile: POSIX windres
From: Johannes Schindelin @ 2017-01-09 8:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven Penny, Johannes Sixt, git
In-Reply-To: <xmqqtw99x70u.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Sun, 8 Jan 2017, Junio C Hamano wrote:
> Steven Penny <svnpenn@gmail.com> writes:
>
> > When environment variable POSIXLY_CORRECT is set, the "input -o
> > output" syntax is not supported.
> >
> > http://cygwin.com/ml/cygwin/2017-01/msg00036.html
> >
> > Signed-off-by: Steven Penny <svnpenn@gmail.com>
> > ---
>
> Who other than cygwin build uses this target? Git for Windows?
Yes, Git for Windows uses this target, as did msysGit (and I suspect
Hannes' setup).
The resources are built correctly in Git for Windows SDK with this patch,
and I just verified that the windres shipped with the last msysGit (AKA
Git for Windows 1.x' SDK) handles the -i flag correctly, too. That is, at
least windres.exe included in binutils-2.19.1-mingw32-bin.tar.gz (which
was current at the time I updated msysGit on Feb 19 2009) can handle it.
So: ACK
Ciao,
Dscho
P.S.: I applied this patch to Git for Windows' `master`:
https://github.com/git-for-windows/git/commit/744120c602
^ permalink raw reply
* Re: [PATCH v4 4/4] t7800: run both builtin and scripted difftool, for now
From: Johannes Schindelin @ 2017-01-09 7:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Aguilar, Dennis Kaarsemaker, Paul Sbarra
In-Reply-To: <xmqqtw99ypvq.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Sun, 8 Jan 2017, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
> > This is uglier than a simple
> >
> > touch "$GIT_EXEC_PATH/use-builtin-difftool"
> >
> > of course. But oh well.
>
> That is totally irrelevant.
>
> The more important point is that we do the same set of tests so
> instead of running just one, we run BOTH.
And the most important point is that we do all of this only during a
hopefully brief period in time that is mostly spent on reviewing the code
and finding serious bugs and fixing them.
During that period (which I would expect to be spent completely inside
`pu`), the cross-validation does not have to be beautiful, but correct.
And even more importantly: it has to come at a minimal integration cost,
in case David decides to add another test case to t7800.
And after that period, we retire the Perl script and switch to the builtin
difftool and simply drop this patch to cross-validate both difftools'
outputs with one another.
At which point all of this safe-guarding and indenting and all of those
changes that are just meant to cross-validate the output during that
hopefully brief period of time will become moot and all the work spent on
those changes will be worthless.
Oh, at that point also all review that went into *this* patch will have
been spent in vain.
In short: can we please move on to reviewing the *actual* builtin difftool
and spend our effort on making sure that it is correct?
Ciao,
Johannes
^ permalink raw reply
* Re: [PATCH v4 1/4] Avoid Coverity warning about unfree()d git_exec_path()
From: Johannes Schindelin @ 2017-01-09 7:49 UTC (permalink / raw)
To: Junio C Hamano
Cc: Stefan Beller, git@vger.kernel.org, David Aguilar,
Dennis Kaarsemaker, Paul Sbarra
In-Reply-To: <xmqqy3ylyqhf.fsf@gitster.mtv.corp.google.com>
Hi,
On Sun, 8 Jan 2017, Junio C Hamano wrote:
> How about explaining it like this then?
>
> (only the log message has been corrected; diff is from the original).
>
> commit c9bb5d101ca657fa466afa8c4368c43ea7b7aca8
> Author: Johannes Schindelin <johannes.schindelin@gmx.de>
> Date: Mon Jan 2 17:22:33 2017 +0100
>
> git_exec_path: avoid Coverity warning about unfree()d result
>
> Technically, it is correct that git_exec_path() returns a possibly
> malloc()ed string returned from system_path(), and it is sometimes
> not allocated. Cache the result in a static variable and make sure
> that we call system_path() only once, which plugs a potential leak.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sounds good to me.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] connect: handle putty/plink also in GIT_SSH_COMMAND
From: Johannes Schindelin @ 2017-01-09 7:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Segev Finer
In-Reply-To: <xmqq4m1911mf.fsf@gitster.mtv.corp.google.com>
Hi Junio,
On Sun, 8 Jan 2017, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > I suspect that this will break when GIT_SSH_COMMAND, which is meant
> > to be processed by the shell, hence the user can write anything,
> > begins with a one-shot environment variable assignment, e.g.
> >
> > [core] sshcommand = VAR1=VAL1 VAR2=VAL2 //path/to/tortoiseplink
> >
> > One possible unintended side effect of this patch is when VAL1 ends
> > with /plink (or /tortoiseplink) and the command is not either of
> > these, in which case the "tortoiseplink" and "putty" variables will
> > tweak the command line for an SSH implementation that does not want
> > such a tweak to be made. There may be other unintended fallouts.
>
> Thinking about this further, as the sshcommand (or GIT_SSH_COMMAND)
> interface takes any shell-interpretable commands, the first "token"
> you see is not limited to a one-shot environment assignment. It
> could even be "cmd1 && cmd2 && ..." or even:
>
> if test -f ${TPLINK:=//path/to/tortoiseplink}
> then
> exec "$TPLINK" "$@"
> elif test -f ${PLINK:=//path/to/plink}
> exec "$PLINK" "$@"
> else
> echo >&2 no usable ssh on this host
> fi
Sure, it could be all of that. It could even blast through the environment
limits in some environments on some platforms, but not on others. It could
automatically transfer bitcoins whenever a connection to github.com is
attempted. It could start the camera and build a time-lapse of "every time
I pushed or fetched a repository", as an art project. It could shut down
the computer.
It could do all of that.
In practice, however, what users realistically do is to use
GIT_SSH_COMMAND whenever they need to override the ssh command with
options.
This is the common case, and that is what we must make less cumbersome to
use.
If you feel strongly about your contrived examples possibly being affected
by this patch, we could easily make this conditional on
1) no '&&' or '||' being found on the command-line, and
2) argv[0] not containing an '='
Another approach would be to verify that argv[i] starts with '-' for
non-zero i.
But do we really need to do that?
Let's have a very brief look at the amount of work required to come up
with a false positive (I am not so much concerned about any power user
writing elaborate shell expressions that may call plink.exe: those power
users will simply have to continue to use their own -P => -p and -batch
hacks):
The logic kicks in if the split command-line's first component has a
basename `plink` or `tortoiseplink` (possibly with `.exe` suffix). The
only way this logic can kick in by mistake is if the first component is
*not* the command to call *and* if the first component *still* has a
basename of `plink` or `tortoiseplink`.
That means that the user has to specify something like
HAHAHA_IT_IS_NOT=/plink.exe ssh
as GIT_SSH_COMMAND.
Now, let's take a *very* brief look at the question how likely it is to
have a basename of `plink` or `tortoiseplink`. Remember, there are two
ways that the basename can be a specific term: either the original string
is already equal to that term, or it ends in a slash followed by the term.
That is, either the first component refers to plink.exe/tortoiseplink.exe, i.e.
it would be a *true* positive. Or the first component would end in
"/plink" or "/tortoiseplink" (possibly with the `.exe` suffix) *and not be
a command*. But how likely is it to specify a non-command (such as a
per-process variable assignment) that specifically mentions plink or
tortoiseplink?
Is it even realistic to expect users to specify values for GIT_SSH_COMMAND
that contain "plink" as a substring when they do *not* want to call plink
at all?
After thinking a bit longer than I had originally planned about it, my
answer is: no. No, I do not think it is realistic. I fully expect *no*
user to have a GIT_SSH_COMMAND containing even a substring "plink"
*anywhere*, unless they do, in fact, want to call plink or tortoiseplink.
My main aim with Git for Windows is to improve the user experience, and
the patch in question does do that. Of course, I also try to avoid
breaking existing setups while improving the user experience, and
I believe that it is safe to assume that the patch in question in all
likelihood does not break any existing setup.
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox