git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Felipe Contreras <felipe.contreras@gmail.com>
Cc: Johannes Sixt <j.sixt@viscovery.net>, git@vger.kernel.org
Subject: Re: [PATCH] git-remote-testgit: avoid process substitution
Date: Thu, 25 Apr 2013 13:06:06 -0700	[thread overview]
Message-ID: <7vsj2e2x5d.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CAMP44s3LhYt+eNaKWyoDWAPtepaOKXLhYsPXg5dPjYN8MoGA-w@mail.gmail.com> (Felipe Contreras's message of "Thu, 25 Apr 2013 14:24:47 -0500")

Felipe Contreras <felipe.contreras@gmail.com> writes:

> On Thu, Apr 25, 2013 at 1:25 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>
>>>>> ...
>>>>> +             git for-each-ref --format='%(refname) %(objectname)' |
>>>>> +             while read ref a
>>>>>               do
>>>>> -                     test $a == $b && continue
>>>>> +                     case "$before" in
>>>>> +                     *"$ref $a"*)
>>>>> +                             continue
>>>>
>>> I wonder if we should bother with this at all. The purpose of the code
>>> was mainly to show to users that they should report the success only
>>> if the refs have been updated, but the code is becoming more
>>> obfuscated, a comment should do the trick. And then, we can just
>>> report success for all the refs (and explain in the comment why).
>>
>> Are you proposing to say "ok $ref" to everything we see in the
>> resulting repository, even the ones the caller of remote-testgit did
>> not ask us to do anything with?
>>
>> Wouldn't the caller be surprised if we did so?
>
> Why would it?  The only effective difference is what you'll see
> reported in the UI, but there's no user here.

You are correct that it affects only the UI, but isn't that because
the current implementation of push_update_refs_status() blindly
accepts whatever 'ok' response says without checking the ref
mentioned against what it tried to push out?  I was wondering if
that codepath should stay that way forever, or if we may want add
sanity checks later.  If the latter, I suspect this would manifest
as an ancient bug to say 'ok' for everything we have instead of what
we actually pushed out (of course, the explanation in the comment
would help).

So I am OK with that simpler approach.  Care to roll the conclusion
of your idea into a patch?

By the way, I noticed that Documentation/gitremote-helpers.txt does
not even mention these 'ok' responses for 'export' command, but they
should be the same as responses to 'push'. Perhaps we can share some
text between the two?

  reply	other threads:[~2013-04-25 20:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-22 20:07 What's cooking in git.git (Apr 2013, #07; Mon, 22) Junio C Hamano
2013-04-23 19:31 ` What's cooking in git.git (Apr 2013, #08; Tue, 23) Junio C Hamano
2013-04-24  7:57   ` Johannes Sixt
2013-04-24  8:04     ` Felipe Contreras
2013-04-24  8:30       ` Johannes Sixt
2013-04-25  5:56         ` [PATCH] git-remote-testgit: avoid process substitution Johannes Sixt
2013-04-25 14:57           ` Junio C Hamano
2013-04-25 17:50             ` Felipe Contreras
2013-04-25 18:25               ` Junio C Hamano
2013-04-25 19:24                 ` Felipe Contreras
2013-04-25 20:06                   ` Junio C Hamano [this message]
2013-04-25 20:31                     ` Felipe Contreras
2013-04-26 21:56           ` Felipe Contreras
2013-04-26 22:25             ` Junio C Hamano
2013-04-26 22:45               ` Felipe Contreras
2013-04-26 23:26                 ` Re* " Junio C Hamano
2013-04-27 19:13                   ` Johannes Sixt
2013-04-29 17:36                     ` Junio C Hamano
2013-04-29 17:41                       ` [PATCH 0/3] De-bashing remote-testgit Junio C Hamano
2013-04-29 17:41                         ` [PATCH 1/3] git-remote-testgit: avoid process substitution Junio C Hamano
2013-04-29 17:41                         ` [PATCH 2/3] git-remote-testgit: further remove some bashisms Junio C Hamano
2013-04-29 17:41                         ` [PATCH 3/3] git-remote-testgit: build it to run under $SHELL_PATH 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

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

  git send-email \
    --in-reply-to=7vsj2e2x5d.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=felipe.contreras@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=j.sixt@viscovery.net \
    /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.
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 NNTP newsgroup(s).