git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Miguel Torroja <miguel.torroja@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Luke Diamand <luke@diamand.org>, Git Users <git@vger.kernel.org>,
	Lars Schneider <larsxschneider@gmail.com>
Subject: Re: [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes
Date: Thu, 13 Jul 2017 09:12:32 +0200	[thread overview]
Message-ID: <CAKYtbVaxR0sdL_k=vy-aT5wEzvCTzDcM6Q-i0hO6jLMzjEUwmA@mail.gmail.com> (raw)
In-Reply-To: <xmqqr2xl1suy.fsf@gitster.mtv.corp.google.com>

Thanks,

I've just sent in reply to your previous e-mail three different patches.

* The first patch is just to show some broken tests,
* Second patch is to fix the original issue I had (the one that
initiated this thread)
* Third patch is the one that filters out "info" messages in p4CmdList
(this time default is reversed and set to False, what is the original
behaviour). The two test cases that are cured with this change have to
set explicitely skip_info=True.


On Wed, Jul 12, 2017 at 7:13 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Miguel Torroja <miguel.torroja@gmail.com> writes:
>
>> The motivation for setting skip_info default to True is because any
>> extra message  output by a p4 trigger to stdout, seems to be reported
>> as {'code':'info'} when the p4 command output is marshalled.
>>
>> I though it was the less intrusive way to filter out the verbose
>> server trigger scripts, as some commands are waiting for a specific
>> order and size of the list returned e.g:
>>
>>  def p4_last_change():
>>      results = p4CmdList(["changes", "-m", "1"])
>>      return int(results[0]['change'])
>>  .
>>  def p4_describe(change):
>>     ds = p4CmdList(["describe", "-s", str(change)])
>>     if len(ds) != 1:
>>         die("p4 describe -s %d did not return 1 result: %s" % (change, str(ds)))
>>
>> Previous examples would be broken if we allow extra "info" marshalled
>> messages to be exposed.
>>
>> In the case of the command that was broken with the new default
>> behaviour , when calling modfyChangelistUser, it is waiting for any
>> message with 'data' that is not an error to consider command was
>> succesful
>
> I somehow feel that this logic is totally backwards.  The current
> callers of p4CmdList() before your patch did not special case an
> entry that was marked as 'info' in its 'code' field.  Your new
> caller, which switched from using p4_read_pipe_lines() to p4CmdList()
> is one caller that you *know* wants to special case such an entry
> and wanted to skip.
>
> Your original patch that was queued to 'pu' for a while and then
> ejected from it after Travis saw an issue *assumed* that all other
> callers to p4CmdList() also want to special case such an entry, and
> that is why it made skip_info parameter default to True.
>
> The difference between knowing and assuming is the cause of the bug
> your original patch introduced into modifyChangelistUser().
>
> The way I read Luke's suggestion was that you can avoid making the
> same mistake by not changing the behaviour for existing callers you
> didn't look at.
>
> Instead of assuming everybody else do not want an entry with 'code'
> set to 'info', assume all the callers before your patch is doing
> fine, and when you *know* some of them are better off ignoring such
> an entry, explicitly tell them to do so, by:
>
>  * The first patch adds skip_info parameter that defaults to False
>    to p4CmdList() and do the special casing when it is set to True.
>
>  * The second patch updates p4ChangesForPaths() to use the updated
>    p4CmdList() and pass skip_info=True.  It is OK to squash this
>    step into the first patch.
>
>  * The third and later patches, if you need them, each examines an
>    existing caller of p4CmdList(), and add a new test to demonstrate
>    the existing breakage that comes from not ignoring an entry whose
>    'code' is 'info'.  That test would serve as a good documentation
>    to explain why it is better for the caller to pass skip_info=True,
>    so the same patch would also update the code to do so.
>
> While I was thinking the above through, here are a few cosmetic
> things that I noticed.  There is another comma that is not followed
> by a space in existing code that might want to be corrected in a
> clean-up patch but that is totally outside of the scope of this
> series.
>
> Thanks.
>
>  git-p4.py | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/git-p4.py b/git-p4.py
> index 1facf32db7..0d75753bce 100755
> --- a/git-p4.py
> +++ b/git-p4.py
> @@ -1501,7 +1501,7 @@ class P4Submit(Command, P4UserMap):
>          c['User'] = newUser
>          input = marshal.dumps(c)
>
> -        result = p4CmdList("change -f -i", stdin=input,skip_info=False)
> +        result = p4CmdList("change -f -i", stdin=input, skip_info=False)
>          for r in result:
>              if r.has_key('code'):
>                  if r['code'] == 'error':
> @@ -1575,7 +1575,7 @@ class P4Submit(Command, P4UserMap):
>                  files_list.append(value)
>                  continue
>          # Output in the order expected by prepareLogMessage
> -        for key in ['Change','Client','User','Status','Description','Jobs']:
> +        for key in ['Change', 'Client', 'User', 'Status', 'Description', 'Jobs']:
>              if not change_entry.has_key(key):
>                  continue
>              template += '\n'

  parent reply	other threads:[~2017-07-13  7:12 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-06-20 12:19 [PATCH] git-p4: changelist template with p4 -G change -o Miguel Torroja
2017-06-22 17:32 ` Junio C Hamano
2017-06-24 11:49   ` Luke Diamand
2017-06-24 12:38     ` miguel torroja
2017-06-24 17:36     ` Lars Schneider
     [not found]       ` <CAKYtbVbGekXGAyPd7HeLot_MdZkp7-1Ss-iAi7o8ze2b+sNB6Q@mail.gmail.com>
2017-06-27  9:20         ` miguel torroja
2017-06-27 19:17           ` [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes Miguel Torroja
2017-06-28  4:08             ` Junio C Hamano
2017-06-28  9:54               ` Luke Diamand
2017-06-28 13:14                 ` miguel torroja
     [not found]                   ` <CAE5ih7-x45MD1H6Ahr5oCVtTjgbBkeP4GbKCGB-Cwk6BSQwTcw@mail.gmail.com>
2017-06-29 22:41                     ` miguel torroja
2017-06-30  7:56                       ` Luke Diamand
2017-06-30  8:22                         ` miguel torroja
2017-06-29 22:46                     ` Miguel Torroja
2017-06-30  8:26                       ` Lars Schneider
2017-06-30  9:41                         ` Miguel Torroja
2017-06-30 10:13                           ` Lars Schneider
2017-06-30 16:02                             ` Miguel Torroja
2017-07-03 22:53                               ` Miguel Torroja
2017-07-03 22:57                             ` Miguel Torroja
2017-07-11  8:35                               ` Luke Diamand
2017-07-11 22:35                                 ` Miguel Torroja
2017-07-11 22:53                                 ` Miguel Torroja
2017-07-12  8:25                                   ` Luke Diamand
2017-07-12 10:16                                     ` Miguel Torroja
2017-07-12 17:13                                       ` Junio C Hamano
2017-07-13  7:00                                         ` [PATCH 1/3] git-p4: git-p4 tests with p4 triggers Miguel Torroja
2017-07-13  7:00                                           ` [PATCH 2/3] git-p4: parse marshal output "p4 -G" in p4 changes Miguel Torroja
2017-07-13  7:00                                           ` [PATCH 3/3] git-p4: filter for {'code':'info'} in p4CmdList Miguel Torroja
2017-07-13  7:12                                         ` Miguel Torroja [this message]
2017-07-13 19:30                                           ` [PATCH] git-p4: parse marshal output "p4 -G" in p4 changes Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKYtbVaxR0sdL_k=vy-aT5wEzvCTzDcM6Q-i0hO6jLMzjEUwmA@mail.gmail.com' \
    --to=miguel.torroja@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=larsxschneider@gmail.com \
    --cc=luke@diamand.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).