Re: git-gui: Error on restoring defaults

+cc Pat who maintains git-gui On Thu, Jun 29, 2017 at 6:13 PM, Samuel Leslie wrote: > Hi there, > > When selecting “Restore Defaults” in the Options dialogue via the Edit -> > Options menu the following application error is received: > > window name "!paving" already exists in

Re: [PATCH 2/2] commit-template: add new line before status information

On Thu, 2017-06-29 at 11:17 -0700, Junio C Hamano wrote: > The rationale of this has changed in this final version, hasn't it, > especially with the removal of the "include/only warning" bit? > > We used to add a blank line to separate the "we are committing for > somebody else", which is an

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

On Thu, 2017-06-29 at 10:56 -0700, Junio C Hamano wrote: > When I said "I would have ... if I were doing this", I merely meant > exactly that---as I weren't doing it, I left it up to you.  But you > did it the way anyways, which is very nice of you ;-). > It made a *lot* of sense, that's why. :)

git-gui: Error on restoring defaults

Hi there, When selecting “Restore Defaults” in the Options dialogue via the Edit -> Options menu the following application error is received: window name "!paving" already exists in parent     while executing "ttk::frame $w.!paving"     (procedure "pave_toplevel" line 4)     invoked from within

[PATCH] recursive submodules: detach HEAD from new state, keeping branches sane

When a submodule is on a branch and in its superproject you run a recursive checkout, the branch of the submodule is updated to what the superproject checks out. This is very unexpected. Instead detach the HEAD when updating it. Signed-off-by: Stefan Beller --- submodule.c

[PATCH 08/25] diff.c: migrate emit_line_checked to use emit_diff_symbol

Add a new flags field to emit_diff_symbol, that will be used by context lines for: * white space rules that are applicable (The first 12 bits) Take a note in cahe.c as well, when this ws rules are extended we have to fix the bits in the flags field. * how the rules are evaluated (actually this

[PATCH 07/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_NO_LF_EOF

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/diff.c b/diff.c index 6e48a129ed..488096b757 100644 --- a/diff.c +++ b/diff.c @@ -561,6 +561,7 @@

[PATCH 21/25] diff.c: buffer all output if asked to

Introduce a new option 'emitted_symbols' in the struct diff_options which controls whether all output is buffered up until all output is available. It is set internally in diff.c when necessary. We'll have a new struct 'emitted_string' in diff.c which will be used to buffer each line. The

[PATCH 00/25] Reroll of sb/diff-color-moved.

Reroll of sb/diff-color-moved, applies on top of the hashmap patches[1]. * Supports different whitespace modes correctly now (and has a test for trivial white space changes) * The fixups[2] have been squashed. Thanks, Stefan [1]

[PATCH 09/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_WORDS[_PORCELAIN]

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 42 ++ 1 file changed, 26 insertions(+), 16 deletions(-) diff --git a/diff.c b/diff.c index e5430d56da..85bfd9310d 100644 --- a/diff.c +++

[PATCH 20/25] diff.c: emit_diff_symbol learns about DIFF_SYMBOL_SUMMARY

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 71 ++ 1 file changed, 41 insertions(+), 30 deletions(-) diff --git a/diff.c b/diff.c index 5a9c55736d..2db0d7c0f5

[PATCH 22/25] diff.c: color moved lines differently

When a patch consists mostly of moving blocks of code around, it can be quite tedious to ensure that the blocks are moved verbatim, and not undesirably modified in the move. To that end, color blocks that are moved within the same patch differently. For example (OM, del, add, and NM are different

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

Signed-off-by: Stefan Beller --- Documentation/config.txt | 15 +-- Documentation/diff-options.txt | 34 ++ 2 files changed, 47 insertions(+), 2 deletions(-) diff --git a/Documentation/config.txt b/Documentation/config.txt

[PATCH 13/25] diff.c: emit_diff_symbol learns about DIFF_SYMBOL_BINARY_FILES

we could save a little bit of memory when buffering in a later mode by just passing the inner part ("%s and %s", file1, file 2), but those a just a few bytes, so instead let's reuse the implementation from DIFF_SYMBOL_HEADER and keep the whole line around. Signed-off-by: Stefan Beller

[PATCH 11/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_FILEPAIR_{PLUS, MINUS}

We have to use fprintf instead of emit_line, because we want to emit the tab after the color. This is important for ancient versions of gnu patch AFAICT, although we probably do not want to feed colored output to the patch utility, such that it would not matter if the trailing tab is colored. Keep

[PATCH 17/25] diff.c: convert show_stats to use emit_diff_symbol

We call print_stat_summary from builtin/apply, so we still need the version with a file pointer, so introduce print_stat_summary_0 that uses emit_string machinery and keep print_stat_summary with the same arguments around. Signed-off-by: Stefan Beller Signed-off-by: Junio C

[PATCH 16/25] diff.c: convert emit_binary_diff_body to use emit_diff_symbol

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 63 ++- 1 file changed, 46 insertions(+), 17 deletions(-) diff --git a/diff.c b/diff.c index 48f719fb07..f5a14359ae 100644

[PATCH 18/25] diff.c: convert word diffing to use emit_diff_symbol

The word diffing is not line oriented and would need some serious effort to be transformed into a line oriented approach, so just go with a symbol DIFF_SYMBOL_WORD_DIFF that is a partial line. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano ---

[PATCH 10/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_INCOMPLETE

The context marker use the exact same output pattern, so reuse it. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/diff.c b/diff.c index 85bfd9310d..b2b2a19fcf

[PATCH 23/25] diff.c: color moved lines differently, plain mode

Add the 'plain' mode for move detection of code. This omits the checking for adjacent blocks, so it is not as useful. If you have a lot of the same blocks moved in the same patch, the 'Zebra' would end up slow as it is O(n^2) (n is number of same blocks). So this may be useful there and is

[PATCH 14/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_REWRITE_DIFF

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 35 +-- 1 file changed, 21 insertions(+), 14 deletions(-) diff --git a/diff.c b/diff.c index 1d0f8b509f..5c428e02b6 100644 --- a/diff.c +++ b/diff.c @@

[PATCH 15/25] submodule.c: migrate diff output to use emit_diff_symbol

As the submodule process is no longer attached to the same file pointer 'o->file' as the superprojects process, there is a different result in color.c::check_auto_color. That is why we need to pass coloring explicitly, such that the submodule coloring decision will be made by the child process

[PATCH 24/25] diff.c: add dimming to moved line detection

Any lines inside a moved block of code are not interesting. Boundaries of blocks are only interesting if they are next to another block of moved code. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- color.h| 2 +

[PATCH 19/25] diff.c: emit_diff_symbol learns about DIFF_SYMBOL_STAT_SEP

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/diff.c b/diff.c index e0d39d04da..5a9c55736d 100644 --- a/diff.c +++ b/diff.c @@ -571,6 +571,7 @@ enum

[PATCH 04/25] diff.c: introduce emit_diff_symbol

In a later patch we want to buffer all output before emitting it as a new feature ("markup moved lines") conceptually cannot be implemented in a single pass over the output. There are different approaches to buffer all output such as: * Buffering on the char level, i.e. we'd have a char[] which

[PATCH 01/25] diff.c: readability fix

We already have dereferenced 'p->two' into a local variable 'two'. Use that. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/diff.c b/diff.c index

[PATCH 03/25] diff.c: factor out diff_flush_patch_all_file_pairs

In a later patch we want to do more things before and after all filepairs are flushed. So factor flushing out all file pairs into its own function that the new code can be plugged in easily. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano ---

[PATCH 02/25] diff.c: move line ending check into emit_hunk_header

The emit_hunk_header() function is responsible for assembling a hunk header and calling emit_line() to send the hunk header to the output file. Its only caller fn_out_consume() needs to prepare for a case where the function emits an incomplete line and add the terminating LF. Instead make sure

[PATCH 06/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_FRAGINFO

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/diff.c b/diff.c index 75b996c4cf..6e48a129ed 100644 --- a/diff.c +++ b/diff.c @@ -561,6 +561,7 @@ static void

[PATCH 12/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_HEADER

The header is constructed lazily including line breaks, so just emit the raw string as is. Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 28 1 file changed, 20 insertions(+), 8 deletions(-) diff

[PATCH 05/25] diff.c: emit_diff_symbol learns DIFF_SYMBOL_CONTEXT_MARKER

Signed-off-by: Stefan Beller Signed-off-by: Junio C Hamano --- diff.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/diff.c b/diff.c index 4637368d59..75b996c4cf 100644 --- a/diff.c +++ b/diff.c @@ -561,13 +561,20 @@ static

[PATCHv2 1/2] hashmap.h: compare function has access to a data field

When using the hashmap a common need is to have access to arbitrary data in the compare function. A couple of times we abuse the keydata field to pass in the data needed. This happens for example in patch-ids.c. This patch changes the function signature of the compare function to have one more

[PATCHv2 0/2] Introduce data field in hashmap and migrate docs to header

v2: addressed all but the last point of Jonathan Nieder. Thanks, Stefan v1: https://public-inbox.org/git/xmqqpodnvmmw@gitster.mtv.corp.google.com/ for context why we need a new data field. Implement that. Once upon a time we had a long discussion where to put documentation best. The

[PATCHv2 2/2] hashmap: migrate documentation from Documentation/technical into header

While at it, clarify the use of `key`, `keydata`, `entry_or_key` as well as documenting the new data pointer for the compare function. Signed-off-by: Stefan Beller --- Documentation/technical/api-hashmap.txt | 309 hashmap.h

Re: [PATCH 6/6] diff.c: detect blocks despite whitespace changes

On Thu, Jun 29, 2017 at 2:01 PM, Stefan Beller wrote: > On Tue, Jun 27, 2017 at 10:06 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> This probably deserves a bit more illustration of how I envision the >> code should evolve. >>

Re: [PATCH 2/2] hashmap: migrate documentation from Documentation/technical into header

Took all suggestions so far, but the last one: > > Probably worth mentioning this is a convenience wrapper for iter_init > + iter_next, like the Documentation/technical/ text did. No. The code to observe that this is a convenience wrapper IS RIGHT THERE (it's a header file), and I find this

Fatura n.6760

İyi Günler Tamamlanmış işler için rapor ve faturanız ekte gönderilmiştir. Lütfen ödemenizi geciktirmeyiniz. En iyi dileklerimizle Murat Başaran, HAVELSAN A.Ş. TEL : 0312 219 57 97 (35 hat Pbx) FAKS : 0312 219 57 87 pdf_fatura.rar Description: Binary data

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

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 description. Some p4 triggers in the server side generate some warnings when executed.

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

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 - unresolvable host in P4PORT >> should display error), for me it's very weird too as

[PATCH v2 5/6] grep: remove regflags from the public grep_opt API

Refactor calls to the grep machinery to always pass opt.ignore_case & opt.extended_regexp_option instead of setting the equivalent regflags bits. The bug fixed when making -i work with -P in commit 9e3cbc59d5 ("log: make --regexp-ignore-case work with --perl-regexp", 2017-05-20) was really just

[PATCH v2 6/6] grep: remove redundant REG_NEWLINE when compiling fixed regex

Remove the redundant REG_NEWLINE regcomp() flag from the code that compiles a fixed-string regular-expression. The REG_NEWLINE causes metacharacters such as "." to match a newline, since the basic_regex_quote_buf() function being called here escapes all metacharacters using REG_NEWLINE is

[PATCH v2 4/6] grep: remove redundant and verbose re-assignments to 0

Remove the redundant re-assignments of the fixed/pcre1/pcre2 fields to zero right after the entire struct has been set to zero via memset(...). See an earlier related cleanup commit e0b9f8ae09 ("grep: remove redundant regflags assignments", 2017-05-25) for an explanation of why the code was

[PATCH v2 2/6] grep: adjust a redundant grep pattern type assignment

Adjust a now-redundant assignment to extended_regexp_option to make it zero if grep.extendedRegexp is not set. This is always called right after init_grep_defaults() which memsets the entire structure to 0, so there's no need to set it again to zero. However the reason for the if/else pattern is

[PATCH v2 1/6] grep: remove redundant double assignment to 0

Stop assigning 0 to the extended_regexp_option field right after we've zeroed out the entire struct with memset() just a few lines earlier. Unlike some of the code being refactored in subsequent commits, this was always completely redundant. See the original code introduced in 84befcd0a4 ("grep:

[PATCH v2 0/6] grep: remove redundant code & reflags from API

Addresses comments from Stefan Beller (thanks!). I looked into it and the REG_NEWLINE flag was redundant in 1/2 cases, see 6/6 for the removal of that. I looked into refactoring 5/6 as noted in 87zicqirrg@gmail.com, but for the reasons now explained in the last paragraph of 5/6 decided not to

[PATCH v2 3/6] grep: remove redundant "fixed" field re-assignment to 0

Remove the redundant re-assignment of the fixed field to zero right after the entire struct has been set to zero via memset(...). Unlike some nearby commits this pattern doesn't date back to the pattern described in e0b9f8ae09 ("grep: remove redundant regflags assignments", 2017-05-25), instead

[PATCH] merge-recursive: use DIFF_XDL_SET macro

Instead of implementing this on our own, just use a convenience macro. Signed-off-by: Stefan Beller --- merge-recursive.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/merge-recursive.c b/merge-recursive.c index 59e5ee41a8..1494ffdb82 100644 ---

Re: [PATCH 2/2] hashmap: migrate documentation from Documentation/technical into header

Stefan Beller wrote: > Subject: hashmap: migrate documentation from Documentation/technical into > header > > While at it, clarify the use of `key`, `keydata`, `entry_or_key` as well > as documenting the new data pointer for the compare function. > > Signed-off-by: Stefan Beller

Re: [PATCH 6/6] diff.c: detect blocks despite whitespace changes

On Tue, Jun 27, 2017 at 10:06 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Looking at the implementation of get_ws_cleaned_string() that is the >> workhorse of emitted_symbol_cmp_no_ws(), it seems to be doing wrong >> things for various "ignore

Re: Bug: Cannot kill Nodejs process using ctrl + c

Hi, On Wed, 28 Jun 2017, Johannes Schindelin wrote: > On Mon, 26 Jun 2017, Gyandeep Singh wrote: > > [... a bug report ...] This bug report was reposted as https://github.com/git-for-windows/git/issues/1219 In my opinion, it is too Windows-specific for the discussion to continue

Re: [PATCH] completion: optionally disable checkout DWIM

> We could discern between more than just empty vs. non-empty state of > the environment variable, e.g.: > > - if empty/unset, then include "DWIM" suggestions. > - if set to 'config', then query the 'completion.checkoutNoGuess' >configuration variable, and omit "DWIM" suggestions if its

Re: RFC: Missing blob hook might be invoked infinitely recursively

Hi, Jonathan Tan wrote: > Suppose you have missing blob AB12 and CD34 that you now need, so > fetch-blob is invoked. It sends the literals AB12 and CD34 to a new > server endpoint and obtains a packfile, which it then pipes through "git > index-pack". The issue is that "git index-pack" wants to

Re: Warning suggestion for git stash drop

On Thu, Jun 29, 2017 at 11:44 AM, Junio C Hamano wrote: > Laurent Humblet writes: > >> Would it be possible to add an optional Yes/No when doing a 'git stash >> drop'? Something similar as what happens when pushing on a remotely >> checked out

RFC: Missing blob hook might be invoked infinitely recursively

As some of you may know, I'm currently working on support for partial clones/fetches in Git (where blobs above a user-specified size threshold are not downloaded - only their names and sizes are downloaded). To do this, the client repository needs to be able to download blobs at will whenever it

Re: [PATCH v8 6/6] convert: add "status=delayed" to filter process protocol

> On 29 Jun 2017, at 20:34, Junio C Hamano wrote: > > You seem to have squashed an unrelated "table-driven" clean-up into > this step. While I think the end result looks good, I would have > liked to see it as a separate step, either as a preparatory "now we > are going to

Re: Warning suggestion for git stash drop

Laurent Humblet writes: > Would it be possible to add an optional Yes/No when doing a 'git stash > drop'? Something similar as what happens when pushing on a remotely > checked out branch (with a config setting to turn the warning on/off). > > I know that you can

Re: [PATCH v8 6/6] convert: add "status=delayed" to filter process protocol

You seem to have squashed an unrelated "table-driven" clean-up into this step. While I think the end result looks good, I would have liked to see it as a separate step, either as a preparatory "now we are going to add the third one, let's make it table-driven before doing so" step, or a follow-up

Re: [PATCH 1/2] hashmap.h: compare function has access to a data field

On Thu, Jun 29, 2017 at 11:11 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> I haven't looked at the use of keydata in patch-ids.c and friends to >> decide if that "abuse" claim is correct; if it were the case, should >> we expect that a follow-up

Re: [PATCH 2/2] commit-template: add new line before status information

Kaartic Sivaraam writes: > The commit template adds the optional parts without > a new line to distinguish them. This results in > difficulty in interpreting it's content, specifically > for inexperienced users. > > Add new lines to separate the distinct parts of

Re: [PATCH 5/5] grep: remove regflags from the public grep_opt API

On Thu, Jun 29 2017, Stefan Beller jotted: > On Wed, Jun 28, 2017 at 2:58 PM, Ævar Arnfjörð Bjarmason > wrote: >> Refactor calls to the grep machinery to always pass opt.ignore_case & >> opt.extended_regexp_option instead of setting the equivalent regflags >> bits. >> >> The

Re: [PATCH 1/2] hashmap.h: compare function has access to a data field

Junio C Hamano writes: > I haven't looked at the use of keydata in patch-ids.c and friends to > decide if that "abuse" claim is correct; if it were the case, should > we expect that a follow-up patch to clean up the existing mess by > using the new mechanism? Or does fixing

Re: [PATCH 1/2] hashmap.h: compare function has access to a data field

Stefan Beller writes: > When using the hashmap a common need is to have access to arbitrary data > in the compare function. A couple of times we abuse the keydata field > to pass in the data needed. This happens for example in patch-ids.c. It is not "arbitrary data"; it is

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

Kaartic Sivaraam writes: > 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 we

Re: [PATCH 2/2] commit-template: add new line before status information

Kaartic Sivaraam writes: > The commit template adds the optional parts without > a new line to distinguish them. This results in > difficulty in interpreting it's content, specifically > for inexperienced users. > > Add new lines to separate the distinct parts of

Re: [PATCH 2/5] grep: remove redundant grep pattern type assignment

On Thu, Jun 29 2017, Stefan Beller jotted: > On Wed, Jun 28, 2017 at 2:58 PM, Ævar Arnfjörð Bjarmason > wrote: >> Remove a redundant assignment to extended_regexp_option to make it >> zero if grep.extendedRegexp is not set. This is always called right >> after

Re: [PATCH 5/5] grep: remove regflags from the public grep_opt API

On Wed, Jun 28, 2017 at 2:58 PM, Ævar Arnfjörð Bjarmason wrote: > Refactor calls to the grep machinery to always pass opt.ignore_case & > opt.extended_regexp_option instead of setting the equivalent regflags > bits. > > The bug fixed when making -i work with -P in commit

Re: [PATCH 3/5] grep: remove redundant "fixed" field re-assignment to 0

On Wed, Jun 28, 2017 at 2:58 PM, Ævar Arnfjörð Bjarmason wrote: > Remove the redundant re-assignment of the fixed field to zero right > after the entire struct has been set to zero via memset(...). > > Unlike some nearby commits this pattern doesn't date back to the > pattern

Re: [PATCH 2/5] grep: remove redundant grep pattern type assignment

On Wed, Jun 28, 2017 at 2:58 PM, Ævar Arnfjörð Bjarmason wrote: > Remove a redundant assignment to extended_regexp_option to make it > zero if grep.extendedRegexp is not set. This is always called right > after init_grep_defaults() which memsets the entire structure to 0. > >

[PATCH 2/2] commit-template: add new line before status information

The commit template adds the optional parts without a new line to distinguish them. This results in difficulty in interpreting it's content, specifically for inexperienced users. Add new lines to separate the distinct parts of the template. --- I tried writing tests to ensure that the new line

[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 we changed the behaviour of the command to align with other people's

Re: [PATCH 2/2] hashmap: migrate documentation from Documentation/technical into header

On 6/28/2017 9:13 PM, Stefan Beller wrote: While at it, clarify the use of `key`, `keydata`, `entry_or_key` as well as documenting the new data pointer for the compare function. Signed-off-by: Stefan Beller --- Documentation/technical/api-hashmap.txt | 309

Re: [GSoC][PATCH 1/6 v2] submodule--helper: introduce for_each_submodule_list

>> This series of patches is based on the 'next' branch. > > The reason not to base on 'master' is...? > The reason it wasn't based on 'master' was that it depended on the commit: dir: create function count_slashes(), which was merged to 'next' a few days back. > The thing is that a topic built

Warning suggestion for git stash drop

Hi all, Would it be possible to add an optional Yes/No when doing a 'git stash drop'? Something similar as what happens when pushing on a remotely checked out branch (with a config setting to turn the warning on/off). I know that you can always get your dropped stash back using git reflog but a

[no subject]

Apply for a loan at 3% reply to this Email for more Info

I need you help pls

HELP ME PLEASE My name is Miss Victoria Jenny looking for a trustworthy, sincere and honest someone like you who can help me in this time of needs. My father is Rufus Okana, during the civil and political crisis in our country, my parents together with my three sisters was poisoned by heartless

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

On 28 June 2017 at 14:14, miguel torroja wrote: > Thanks Luke, > > regarding the error in t9800 (not ok 18 - unresolvable host in P4PORT > should display error), for me it's very weird too as it doesn't seem > to be related to this particular change, as the patch changes