* 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] 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 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: 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 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: [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] 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
* [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] 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
* 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: 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: [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: [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 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: 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: 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: 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: Refreshing index timestamps without reading content
From: Quentin Casasnovas @ 2017-01-09 12:17 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Quentin Casasnovas, Git Mailing List
In-Reply-To: <CACsJy8BRfJG6L49VyC+qsrQ9Arz0gCGpMATpK9uLq61Lx6_Jtg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1736 bytes --]
On Mon, Jan 09, 2017 at 07:02:45PM +0700, Duy Nguyen wrote:
> On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas
> <quentin.casasnovas@oracle.com> wrote:
>
> > 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.
Hey Duy,
Thanks for your answer.
I've played with this a bit last week and added an extra command, which I
called --refresh-stat, which works like your suggested --index. It works
very well with my use case and improves the performances very significantly
on some of our use cases.
It is attached to this e-mail to gather comments, as you suggest, and is
really not meant to be reviewed for inclusion yet as it lacks test cases,
documentation changes, etc. It is just a convenient way to show what I
need and receive comments.
The logic is simple enugh and will just skip calling ie_modified() when
refreshing the index.
Cheers,
Q
[-- Attachment #1.2: 0001-git-update-index-add-refresh-stat-option.patch --]
[-- Type: text/x-diff, Size: 5346 bytes --]
From 461b4f75056fc476db6bbdf8bc3ff6e91a8ad08d Mon Sep 17 00:00:00 2001
From: Quentin Casasnovas <quentin.casasnovas@oracle.com>
Date: Sat, 7 Jan 2017 09:26:29 +0100
Subject: [PATCH] git-update-index: add --refresh-stat option.
git-update-index --refresh, contrary to what the documentation says, not
only will refresh the stat information but will also update the sha1 of the
objects in the working tree if the stat information is found to be
out-of-date.
We add a --refresh-stat option, which like --refresh will update the stat
information, but will assume that any file in the working tree that is
present in the index matches the index - hence prevents unecessarily
reading the files in the working tree. It is different from
--assume-unchanged or --skip-worktree in that the new stat information is
recorded in the index, hence subsequent git update-index --refresh will not
read the files if their mtime hasn't changed.
This sounds like a very dangerous option to give to the user, since it
could potentially cause changed files to be missed, but can be needed when
we are sure the working tree files have not changed and are matching the
index.
Signed-off-by: Quentin Casasnovas <quentin.casasnovas@oracle.com>
---
builtin/update-index.c | 10 ++++++++++
cache.h | 3 +++
read-cache.c | 7 +++++--
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index f3f07e7f1cb2..1215b6a09687 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -777,6 +777,12 @@ static int really_refresh_callback(const struct option *opt,
return refresh(opt->value, REFRESH_REALLY);
}
+static int refresh_stat_callback(const struct option *opt,
+ const char *arg, int unset)
+{
+ return refresh(opt->value, REFRESH_STAT_ONLY);
+}
+
static int chmod_callback(const struct option *opt,
const char *arg, int unset)
{
@@ -934,6 +940,10 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
N_("refresh stat information"),
PARSE_OPT_NOARG | PARSE_OPT_NONEG,
refresh_callback},
+ {OPTION_CALLBACK, 0, "refresh-stat", &refresh_args, NULL,
+ N_("refresh only stat information (assume content has not changed)"),
+ PARSE_OPT_NOARG | PARSE_OPT_NONEG,
+ refresh_stat_callback},
{OPTION_CALLBACK, 0, "really-refresh", &refresh_args, NULL,
N_("like --refresh, but ignore assume-unchanged setting"),
PARSE_OPT_NOARG | PARSE_OPT_NONEG,
diff --git a/cache.h b/cache.h
index a50a61a19787..57d0f9fffbe5 100644
--- a/cache.h
+++ b/cache.h
@@ -611,6 +611,8 @@ extern void *read_blob_data_from_index(struct index_state *, const char *, unsig
#define CE_MATCH_IGNORE_MISSING 0x08
/* enable stat refresh */
#define CE_MATCH_REFRESH 0x10
+/* only stat refresh, assume content hasn't changed */
+#define CE_MATCH_REFRESH_STAT_ONLY 0x20
extern int ie_match_stat(const struct index_state *, const struct cache_entry *, struct stat *, unsigned int);
extern int ie_modified(const struct index_state *, const struct cache_entry *, struct stat *, unsigned int);
@@ -643,6 +645,7 @@ extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
#define REFRESH_IGNORE_MISSING 0x0008 /* ignore non-existent */
#define REFRESH_IGNORE_SUBMODULES 0x0010 /* ignore submodules */
#define REFRESH_IN_PORCELAIN 0x0020 /* user friendly output, not "needs update" */
+#define REFRESH_STAT_ONLY 0x0040 /* do not check content but update stat */
extern int refresh_index(struct index_state *, unsigned int flags, const struct pathspec *pathspec, char *seen, const char *header_msg);
extern struct cache_entry *refresh_cache_entry(struct cache_entry *, unsigned int);
diff --git a/read-cache.c b/read-cache.c
index db5d91064266..e9334094c6f0 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1101,6 +1101,7 @@ static struct cache_entry *refresh_cache_ent(struct index_state *istate,
int ignore_valid = options & CE_MATCH_IGNORE_VALID;
int ignore_skip_worktree = options & CE_MATCH_IGNORE_SKIP_WORKTREE;
int ignore_missing = options & CE_MATCH_IGNORE_MISSING;
+ int assume_content_unchanged = options & CE_MATCH_REFRESH_STAT_ONLY;
if (!refresh || ce_uptodate(ce))
return ce;
@@ -1161,7 +1162,7 @@ static struct cache_entry *refresh_cache_ent(struct index_state *istate,
}
}
- if (ie_modified(istate, ce, &st, options)) {
+ if (!assume_content_unchanged && ie_modified(istate, ce, &st, options)) {
if (err)
*err = EINVAL;
return NULL;
@@ -1206,11 +1207,13 @@ int refresh_index(struct index_state *istate, unsigned int flags,
int quiet = (flags & REFRESH_QUIET) != 0;
int not_new = (flags & REFRESH_IGNORE_MISSING) != 0;
int ignore_submodules = (flags & REFRESH_IGNORE_SUBMODULES) != 0;
+ int refresh_stat_only = (flags & REFRESH_STAT_ONLY) != 0;
int first = 1;
int in_porcelain = (flags & REFRESH_IN_PORCELAIN);
unsigned int options = (CE_MATCH_REFRESH |
(really ? CE_MATCH_IGNORE_VALID : 0) |
- (not_new ? CE_MATCH_IGNORE_MISSING : 0));
+ (not_new ? CE_MATCH_IGNORE_MISSING : 0) |
+ (refresh_stat_only ? CE_MATCH_REFRESH_STAT_ONLY : 0));
const char *modified_fmt;
const char *deleted_fmt;
const char *typechange_fmt;
--
2.11.0
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply related
* Re: Refreshing index timestamps without reading content
From: Quentin Casasnovas @ 2017-01-09 12:22 UTC (permalink / raw)
To: Quentin Casasnovas; +Cc: Duy Nguyen, Git Mailing List
In-Reply-To: <20170109121724.GC7000@chrystal.oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1837 bytes --]
On Mon, Jan 09, 2017 at 01:17:24PM +0100, Quentin Casasnovas wrote:
> On Mon, Jan 09, 2017 at 07:02:45PM +0700, Duy Nguyen wrote:
> > On Thu, Jan 5, 2017 at 6:23 PM, Quentin Casasnovas
> > <quentin.casasnovas@oracle.com> wrote:
> >
> > > 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.
>
>
> Hey Duy,
>
> Thanks for your answer.
>
> I've played with this a bit last week and added an extra command, which I
> called --refresh-stat, which works like your suggested --index. It works
^^^^^^^
Whoops, sorry!
[...] *a bit* like your suggested *--touch*. [...]
I don't really need it to support specific mtime from the CLI for my
different use cases, but if someone has some ideas in how that would be
useful, I can try implementing your --index-info change to support stat
information to be passed around instead of my current simple
implementation.
Q
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 0/5] Localise error headers
From: Michael J Gruber @ 2017-01-09 12:43 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20170104070514.pxdthvilw66ierfz@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 04.01.2017 08:05:
> On Mon, Jan 02, 2017 at 12:14:49PM +0100, Michael J Gruber wrote:
>
>> Currently, the headers "error: ", "warning: " etc. - generated by die(),
>> warning() etc. - are not localized, but we feed many localized error messages
>> into these functions so that we produce error messages with mixed localisation.
>>
>> This series introduces variants of die() etc. that use localised variants of
>> the headers, i.e. _("error: ") etc., and are to be fed localized messages. So,
>> instead of die(_("not workee")), which would produce a mixed localisation (such
>> as "error: geht ned"), one should use die_(_("not workee")) (resulting in
>> "Fehler: geht ned").
>
> I can't say I'm excited about having matching "_" variants for each
> function. Are we sure that they are necessary? I.e., would it be
> acceptable to just translate them always?
We would still need to mark the strings, e.g.
die(N_("oopsie"));
and would not be able to opt out of translating in the code (only in the
po file, by not providing a translation).
>> 1/5 prepares the error machinery
>> 2/5 provides new variants error_() etc.
>> 3/5 has coccinelli rules error(_(E)) -> error_(_(E)) etc.
>> 4/5 applies the coccinelli patches
>>
>> 5/5 is not to be applied to the main tree, but helps you try out the feature:
>> it has changes to de.po and git.pot so that e.g. "git branch" has fully localised
>> error messages (see the recipe in the commit message).
>
> Your patches 4 and 5 don't seem to have made it to the list. Judging
> from the diffstat, I'd guess they broke the 100K limit.
Hmmpf, I didn't know about the limit. In any case, they were simple
results of applying the "make cocci" patches (4/5) resp. providing some
"de" strings to try this out.
In any case, the question is whether we want to tell the user
A: B
where A is in English and B is localised, or rather localise both A and
B (for A in "error", "fatal", "warning"...).
For localising A and B, we'd need this series or something similar. For
keeping the mix, we don't need to do anything ;)
Michael
^ permalink raw reply
* Re: Test failures when Git is built with libpcre and grep is built without it
From: Andreas Schwab @ 2017-01-09 13:05 UTC (permalink / raw)
To: A. Wilcox; +Cc: Jeff King, git
In-Reply-To: <58736B2A.40003@adelielinux.org>
On Jan 09 2017, "A. Wilcox" <awilfox@adelielinux.org> 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
You need to quote the regexp argument, see the line starting with
"test_must_fail" above.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH] connect: handle putty/plink also in GIT_SSH_COMMAND
From: Junio C Hamano @ 2017-01-09 14:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Segev Finer
In-Reply-To: <alpine.DEB.2.20.1701091207480.3469@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > But do we really need to do that?
>>
>> No.
>
> Exactly.
> 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:
I do not understand why you keep arguing.
With No-Exactly exchange, I thought that we established that
* The original auto-detection for GIT_SSH is battle tested and has
worked for us very well. It may probably have covered 99.9% of
the population, and we haven't heard complaints from the
remaining 0.1%.
* The added support for GIT_SSH_COMMAND, because the mechanism
gives more lattitude to end-users to be creative, will have lower
chance of correctly deciding between ssh, tortoiseplink and
plink, but it would still be high enough, say 99%, correct
detection rate.
* It is foolish to add more code to refine the auto-detection to
raise 99% to 99.5%. We know that the approach fundamentally
cannot make the detection rate reach 100%.
The last one can be paraphrased as "perfect is the enemy of good".
But that does not mean that it is OK to leave the system unusable
for 1% of the users. If the auto-detection code does not work
correctly for a tiny minority of users, it is still OK, as long as
we give them an escape hatch to allow them to say "You may not be
able to guess among ssh, tortoiseplink and plink, or you may even
guess incorrectly, so I'll tell you. I am using plink". 99% of
users do not have to know about that escape hatch, but 1% of users
will be helped.
IOW, "give an escape hatch to override auto-detected tortoiseplink
and plink variables" suggestion should be taken as an "in addition
to" suggestion (as opposed to an "instead of" suggestion). I was
not clear in my very first message, and I thought in my second and
my third message I clarified it as such, but probably I wasn't
explicit enough.
In any case, "do this only if the first one token on the command
line does not have '='" we see below is flawed for two reasons and I
think it would not be a workable counter-proposal (besides, it goes
against the "perfect is the enemy of good" mantra).
For one thing, the command line may not be "VAR=VAL cmd", but just
"cmd" that names the path to tortoiseplink, but the leading
directory path that houses tortoiseplink may have a '=' in it, in
which case we would detect it correctly if we didn't have such a
hack, but with the hack we would punt. More importantly, even when
"VAR=VAL cmd" form was caught with the change, it may punt and stop
guessing, but punting alone does not help users by letting them say
"I know you cannot auto-detect, so let me help you---what I have is
PuTTY plink". If it always assumes that the user uses the plain
vanilla ssh, then the change merely changed what incorrect guess the
auto-detection makes from "tortoiseplink" to "vanilla ssh" for a
user who uses the PuTTY variant of plink.
> -- 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
* Re: [PATCH] Makefile: put LIBS after LDFLAGS for imap-send
From: Junio C Hamano @ 2017-01-09 14:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Penny, git
In-Reply-To: <alpine.DEB.2.20.1701091127570.3469@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ...
> 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
Thanks, will queue on my side, too.
^ permalink raw reply
* Re: [PATCH v3] log --graph: customize the graph lines with config log.graphColors
From: Junio C Hamano @ 2017-01-09 14:23 UTC (permalink / raw)
To: Duy Nguyen; +Cc: Jeff King, Git Mailing List
In-Reply-To: <CACsJy8AjW1TrLO28mSUSTc6V+_0kuShf7V-=Pkw3Cw9t7ZRfyw@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
> 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
>> ...
>> 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.
Yup, when Peff said "argv-array", it took me a few breaths, until I
realized that argv-array was merely an array of strings, to convince
myself that the data structure can be used here. If we are going to
use it in more places, we may want to rename it somehow.
^ permalink raw reply
* Re: [PATCH] Makefile: put LIBS after LDFLAGS for imap-send
From: Junio C Hamano @ 2017-01-09 14:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steven Penny, git
In-Reply-To: <alpine.DEB.2.20.1701091127570.3469@virtualbox>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 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
Hmm, I peeked it hoping that you corrected the log message along the
lines of your <alpine.DEB.2.20.1701081953330.3469@virtualbox>, but
it appears that what you queued does not have any extra mention of
cygwin or specifics of the buildchain on top of what Steven posted?
^ 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