Re: [PATCH 0/4] Move unquote_path from git-add--interactive.perl to Git.pm

Looks good. Will queue. Thanks.

Dear Beloved

-- Dear Beloved Friend I am Mrs Nicole Benoite Marois and I have been suffering from ovarian cancer disease and the doctor says that i have just few weeks to leave. I am from (Paris) France but based in Benin republic since eleven years ago as a business woman dealing with gold exportation

Re: [PATCH 2/2] commit-template: distinguish status information unconditionally

Thanks, both looks good. Will queue.

speeding up git pull from a busy gerrit instance over a slow link?

Hi I'm running git version 2.13.1 on Ubuntu 16.04 (x64) I'm connecting over a very slow (international link) to a very busy gerrit server (gerrit.libreoffice.org) using ssh. Ping types are on the order of 200ms. Using GIT_TRACE_PACKET=true, what I am seeing is that the bulk of the time is

[PATCH 2/2] commit-template: distinguish status information unconditionally

The commit template adds the status information without adding a new line to distinguish them in the absence of optional parts. This results in difficulty in interpreting it's content, specifically for inexperienced users. Unconditionally, add new lines to separate the status message from the

[PATCH 1/2] commit-template: remove outdated notice about explicit paths

The notice that "git commit " default to "git commit --only " was there since 756e3ee0 ("Merge branch 'jc/commit'", 2006-02-14). Back then, existing users of Git expected the command doing "git commit --include ", and after the behaviour of the command was changed to align with other people's

Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

> On 30 Jun 2017, at 11:41, Miguel Torroja wrote: > > On Fri, Jun 30, 2017 at 10:26 AM, Lars Schneider > wrote: >> >>> On 30 Jun 2017, at 00:46, miguel torroja wrote: >>> >>> The option -G of p4 (python marshal

Re: [PATCH 0/5] Move unquote_path() from git-add--interactive.perl to Git.pm

On 23/06/17 00:18, Jeff King wrote: > On Thu, Jun 22, 2017 at 11:26:17AM +0100, Phillip Wood wrote: > >> From: Phillip Wood >> >> I'm using this in some scripts and it would be more convenient to have >> it available from Git.pm rather than copying and pasting it each

[PATCH 0/4] Move unquote_path from git-add--interactive.perl to Git.pm

From: Phillip Wood Thanks for the review Junio, I've amended the patches as you suggested. The first patch now removes unquote_path() from add -i as well as adding it to Git.pm. I've fixed the naming issues (the version I sent previously was copied from another

[PATCH 2/4] Git::unquote_path() Handle '\a'

From: Phillip Wood The version copied from git-add--interactive did not handle quoted paths containing '\a'. Signed-off-by: Phillip Wood --- perl/Git.pm | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/perl/Git.pm

[PATCH 4/4] Add tests for Git::unquote_path()

From: Phillip Wood Check that unquote_path() handles spaces and escape sequences properly Signed-off-by: Phillip Wood --- t/t9700/test.pl | 7 +++ 1 file changed, 7 insertions(+) diff --git a/t/t9700/test.pl b/t/t9700/test.pl index

[PATCH 3/4] Git::unquote_path() throw an exception on bad path

From: Phillip Wood This is what the other routines in Git.pm do if there's an error. Signed-off-by: Phillip Wood --- perl/Git.pm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/perl/Git.pm b/perl/Git.pm index

[PATCH 1/4] add -i move unquote_path() to Git.pm

From: Phillip Wood Move unquote_path() from git-add--interactive to Git.pm so it can be used by other scripts. Note this is a straight copy, it does not handle '\a'. That will be fixed in the next commit. Signed-off-by: Phillip Wood ---

Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

On Fri, Jun 30, 2017 at 10:26 AM, Lars Schneider wrote: > >> On 30 Jun 2017, at 00:46, miguel torroja wrote: >> >> The option -G of p4 (python marshal output) gives more context about the >> data being output. That's useful when using the

Re: Bug with automated processing of git status results

On 30/06/17 11:09, Matthieu Moy wrote: Сергей Шестаков writes: I understand that we can turn off core.safecrlf, but it's inconvinient. Note that you can do that without actually changing the config file: git -c core.safecrlf=false status ... Beside that, I

Re: Bug with automated processing of git status results

Сергей Шестаков writes: > I understand that we can turn off core.safecrlf, but it's > inconvinient. Note that you can do that without actually changing the config file: git -c core.safecrlf=false status ... -- Matthieu Moy http://www-verimag.imag.fr/~moy/

Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

> On 30 Jun 2017, at 00:46, miguel torroja wrote: > > The option -G of p4 (python marshal output) gives more context about the > data being output. That's useful when using the command "change -o" as > we can distinguish between warning/error line and real change

Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

The Latest patch I sent was already the squashed version with the fix to pass the tests. Thanks, On Fri, Jun 30, 2017 at 9:56 AM, Luke Diamand wrote: > On 29 June 2017 at 23:41, miguel torroja wrote: >> On Thu, Jun 29, 2017 at 8:59 AM, Luke Diamand

Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes

On 29 June 2017 at 23:41, miguel torroja wrote: > On Thu, Jun 29, 2017 at 8:59 AM, Luke Diamand wrote: >> On 28 June 2017 at 14:14, miguel torroja wrote: >>> Thanks Luke, >>> >>> regarding the error in t9800 (not ok 18 -

Re: [PATCH 25/25] diff: document the new --color-moved setting

On Thu, Jun 29, 2017 at 05:07:10PM -0700, Stefan Beller wrote: > + Small blocks of 3 moved lines or fewer are skipped. If I read the commit messages correctly, this "skipping" process applies to the move detection in general for those smaller blocks and therefore doesn't mean a malicious move

Re: Bug with automated processing of git status results

On Fri, Jun 30, 2017 at 09:00:14AM +0300, Сергей Шестаков wrote: > I am trying to make an automated processing of "git status" results. > I execute the command > > git status -z -uno > > I expect that it has stable output format. However, it still can print > warnings like > > warning: CRLF

Re: git send-email (w/o Cc: stable)

On Thu, Jun 29, 2017 at 03:11:37PM -0700, Luck, Tony wrote: > So there is a "--cc-cmd" option that can do the same as those "-cc" arguments. > Combine that with --suppress-cc=bodycc and things get a bit more automated. Yeah, whatever works for you. I did play with cc-cmd somewhat but can't be

Bug with automated processing of git status results

Hi! I am trying to make an automated processing of "git status" results. I execute the command git status -z -uno I expect that it has stable output format. However, it still can print warnings like warning: CRLF will be replaced by LF in somefile.xml I understand that we can turn off

<    1   2