On Sat, Apr 8, 2017 at 10:25 PM, Ævar Arnfjörð Bjarmason
wrote:
> Add a short -P option as a synonym for the longer --perl-regexp, for
> consistency with the options the corresponding grep invocations
> accept.
>
> This was intentionally omitted in commit 727b6fc3ed ("log --grep:
> accept --basic-
> Change the test library to insert non-alphanumeric ASCII characters
> into the TRASH_DIRECTORY name, that's the directory the test library
> creates, chdirs to and runs each individual test from.
>
> Unless test_fails_on_unusual_directory_names=1 is declared before
> importing test-lib.sh (and i
Danny Sauer writes:
> That's feedback I was looking for - what's the "right" way to get the
> path to the file.
My knee-jerk reaction is that you SHOULDN'T have to do anything
special to "get the path".
I do not have the code in front of me (this is my "down" week after
all), so let me give the
Am 09.04.2017 um 21:11 schrieb Ævar Arnfjörð Bjarmason:
This series changes the test library so that we interpolate the result
of:
perl -e 'print join q[], grep { /[^[:alnum:]]/ and !m<[./]> } map chr,
0x01..0x7f'
Into the trash directory name we generate. Doing this makes 30% of the
test
Change the cleanup phase for the grep command to free the pathspec
struct that's allocated earlier in the same block, and used just a few
lines earlier.
With "grep hi README.md" valgrind reports a loss of 239 bytes now,
down from 351.
The relevant --num-callers=40 --leak-check=full --show-leak-ki
> On 07 Apr 2017, at 14:03, Ben Peart wrote:
>
> To enable future reuse of the filter..process infrastructure,
> split start_multi_file_filter into two separate parts.
>
> start_multi_file_filter will now only contain the generic logic to
> manage the creation and tracking of the child process
> On 07 Apr 2017, at 14:03, Ben Peart wrote:
>
> Add packet_writel() which writes multiple lines in a single call and
> then calls packet_flush_gently(). Update convert.c to use the new
> packet_writel() function from pkt-line.
>
> Signed-off-by: Ben Peart
> ---
> convert.c | 23 ++---
> On 07 Apr 2017, at 14:03, Ben Peart wrote:
>
> Add packet_read_line_gently() to enable reading a line without dying on
> EOF.
>
> Signed-off-by: Ben Peart
> ---
> pkt-line.c | 12
> pkt-line.h | 10 ++
> 2 files changed, 22 insertions(+)
>
> diff --git a/pkt-line.c b/pkt-
Change the test library to insert non-alphanumeric ASCII characters
into the TRASH_DIRECTORY name, that's the directory the test library
creates, chdirs to and runs each individual test from.
Unless test_fails_on_unusual_directory_names=1 is declared before
importing test-lib.sh (and if perl isn't
The "rot13-filter.pl" helper wrote its debug logs always to "rot13-filter.log".
Make this configurable by defining the log file as first parameter of
"rot13-filter.pl".
This is useful if "rot13-filter.pl" is configured multiple times similar to the
subsequent patch 'convert: add "status=delayed" t
The filter log files are modified on comparison. Write the modified log files
to temp files for comparison to fix this.
This is useful for the subsequent patch 'convert: add "status=delayed" to
filter process protocol'.
Signed-off-by: Lars Schneider
---
t/t0021-conversion.sh | 12 ++--
Some `clean` / `smudge` filters might require a significant amount of
time to process a single blob. During this process the Git checkout
operation is blocked and Git needs to wait until the filter is done to
continue with the checkout.
Teach the filter process protocol (introduced in edcc858) to
Mark tests that fail when the TEST_DIRECTORY has a name that's
unusual, i.e. contains control characters, various punctuation etc.
This change is followed by a change that adds the code that picks up
test_fails_on_unusual_directory_names to test-lib.sh, but comes before
that change to not break mo
"rot13-filter.pl" used to write "OUT " to the debug log even in case of
an abort or error. Fix this by writing "OUT " to the debug log only in
the successful case if output is actually written.
This is useful for the subsequent patch 'convert: add "status=delayed" to
filter process protocol'.
Sig
Hi,
in v3 "delay filter" became a series. Patch 1 to 3 are minor t0021 test
adjustments and patch 4 is the actual change.
Most significant change since v2:
If the filter delays a blob, then Git send the filter a "delay-id". Git uses
this "delay-id" as index in an array of delayed "cached entries"
There's a patch now on the ML for an issue with read v.s. read -r in
submodule revealed when the submodule name contains a \.
That fix is fine, but we should do better and structurally arrange our
tests to detect these sorts of issues before they're reported.
This series changes the test library
> On 27 Feb 2017, at 23:11, Jakub Narębski wrote:
>
> W dniu 27.02.2017 o 11:32, Lars Schneider pisze:
>>
>>> On 27 Feb 2017, at 10:58, Jeff King wrote:
>>>
>>> On Sun, Feb 26, 2017 at 07:48:16PM +0100, Lars Schneider wrote:
>>>
+If the request cannot be fulfilled within a reasonable am
> On 27 Feb 2017, at 11:53, Jeff King wrote:
>
> On Mon, Feb 27, 2017 at 11:32:47AM +0100, Lars Schneider wrote:
>
>> ...
>
>>> From Git's side, the loop is something like:
>>>
>>> while (delayed_items > 0) {
>>> /* issue a wait, and get back the status/index pair */
>>> status = send
On 4/9/2017 5:54 AM, Johannes Schindelin wrote:
> Hi Danny,
>
> On Sat, 8 Apr 2017, Danny Sauer wrote:
>> diff --git a/git.c b/git.c
>> index 8ff44f0..e147f01 100644
>> --- a/git.c
>> +++ b/git.c
>> @@ -440,7 +440,7 @@ static struct cmd_struct commands[] = {
>> { "init", cmd_init_db },
>>
Hello,
The following snippet reproduces the issue for me (note the
remote: line in its output):
git --version
rm -rf a b
git init a
cd a
echo first >data
git add data
git commit -m initial
cat >>.git/hooks/post-receive <>data
git add data
git commit -m te
On Sun, Apr 9, 2017 at 11:55 AM, Simon Ruderich wrote:
> Hello,
>
> I like the documentation update and test.
>
> On Sat, Apr 08, 2017 at 11:41:00AM +, Ævar Arnfjörð Bjarmason wrote:
>> [snip]
>>
>> ++
>> +Now when the background process runs `git fetch origin` the references
>> +on `origin-pu
Jacob Keller wrote:
> Agreed. You "take" a lease whenever you push to the remote or when you
> pull from the remote and when you pull into the branch. It should
> store something that tracks both the branch and remote branch together
> so that you can generalize it to multiple remotes.
I don't s
Hi Danny,
On Sat, 8 Apr 2017, Danny Sauer wrote:
> Make git log's `--use-mailmap` argument works if the GIT_DIR &
> GIT_WORK_TREE env vars are set and git is run from outside of work tree.
> Without the NEED_WORK_TREE set on the log subcommand, .mailmap is
> silently not found.
A laudable goal.
Hello,
I like the documentation update and test.
On Sat, Apr 08, 2017 at 11:41:00AM +, Ævar Arnfjörð Bjarmason wrote:
> [snip]
>
> ++
> +Now when the background process runs `git fetch origin` the references
> +on `origin-push` won't be updated, and thus commands like:
> ++
> + git push -
Jeff King wrote:
> > It might be possible to generate these lease tags prior to operations
> > which modify history and then maybe having a way to list them so you
> > can select which one you meant when you try to use force-with-lease..
>
> So yeah, I think that is the more interesting directio
On Sun, Apr 9, 2017 at 1:38 AM, Stefan Haller wrote:
> Jeff King wrote:
>
>> > It might be possible to generate these lease tags prior to operations
>> > which modify history and then maybe having a way to list them so you
>> > can select which one you meant when you try to use force-with-lease..
On Sun, Apr 9, 2017 at 1:38 AM, Stefan Haller wrote:
> Jacob Keller wrote:
>
>> What if we added a separate command something like:
>>
>> git create-lease
>>
>> which you're expected to run at the start of a rewind-y operation and
>> it creates a tag (or some other ref like a tag but in a differe
Jacob Keller wrote:
> What if we added a separate command something like:
>
> git create-lease
>
> which you're expected to run at the start of a rewind-y operation and
> it creates a tag (or some other ref like a tag but in a different
> namespace) which is used by force-with-lease?
The probl
My patch submission (already the retry) "[PATCH 0/4] Gitk Inotify
support" is also pending since 8th of March.
I'm also not sure what I did wrong as I'm not used to those mailing
list programming - or if Paul is just very busy
On Fri, Mar 17, 2017 at 5:53 PM, Jonathan Nieder wrote:
> Hi,
>
> yank
29 matches
Mail list logo
