All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Mike Hommey <mh@glandium.org>
Cc: git@vger.kernel.org, srabbelier@gmail.com
Subject: Re: [PATCH] transport-helper: do not request symbolic refs to remote helpers
Date: Thu, 22 Jan 2015 14:24:38 -0800	[thread overview]
Message-ID: <xmqqh9visbbt.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <20150122221330.GA31912@glandium.org> (Mike Hommey's message of "Fri, 23 Jan 2015 07:13:30 +0900")

Mike Hommey <mh@glandium.org> writes:

> On Thu, Jan 22, 2015 at 09:52:55AM -0800, Junio C Hamano wrote:
>
>> Does the new code avoid regressions for them and if so how?  That is
>> what was needed in the justification.
>> 
>> For remote helpers that support the 'list' command, asking for a
>> symref and asking for a ref that the symref points at both work OK
>> and behave the same, and hopefully that would be true even when the
>> latter is a symref that points yet another ref, so dereferencing
>> only one level on our end when making a request, instead of letting
>> the remote side dereference, is not likely to cause regression.
>
> If I'm not mistaken, in that case with more than one level of symref,
> nothing would break more than it already is, the bug would only not be
> fixed for that case.

Yes, I think we are in agreement.  All is well.

> That said, does this theoretical double indirection actually
> happen in the wild?

With the proliferation of Git-using people and third-party tools
that work with Git, I think the value of asking that question has
diminished.  People do strange things.

And I do not think the patch under discussion does not introduce any
new theoretical funnies; it fixes one known case and leaves the rest
unfixed, without introducing any new breakage, which is perfectly
fine and exactly how we want to make progress.  If the unfixed one
has a real-world need to be fixed, somebody will raise hand, and if
they do not bother to even raise their hands, that is an indication
that it is not worth our time worrying about it.

The only thing we need to avoid, while making "one step at a time"
progress, is to paint ourselves to a corner we cannot get out of by
promising too much --- and I do not think the patch under discussion
does that, either.

      reply	other threads:[~2015-01-22 22:24 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-19  1:35 [PATCH] transport-helper: do not request symbolic refs to remote helpers Mike Hommey
2015-01-22  6:46 ` Junio C Hamano
2015-01-22  7:03   ` Mike Hommey
2015-01-22  7:41     ` Junio C Hamano
2015-01-22  8:06       ` Mike Hommey
2015-01-22 17:52         ` Junio C Hamano
2015-01-22 22:13           ` Mike Hommey
2015-01-22 22:24             ` Junio C Hamano [this message]

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=xmqqh9visbbt.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=mh@glandium.org \
    --cc=srabbelier@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.