All of lore.kernel.org
 help / color / mirror / Atom feed
From: Derrick Stolee <stolee@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
	Srinidhi Kaushik <shrinidhi.kaushik@gmail.com>,
	git@vger.kernel.org, Derrick Stolee <derrickstolee@github.com>,
	Derrick Stolee <dstolee@microsoft.com>
Subject: Re: [PATCH] commit-reach: fix in_merge_bases_many bug
Date: Fri, 2 Oct 2020 16:08:13 -0400	[thread overview]
Message-ID: <ac3ac80d-7f8e-6b16-03fa-1cd38b5d860b@gmail.com> (raw)
In-Reply-To: <xmqqr1qg8kfa.fsf@gitster.c.googlers.com>

On 10/2/2020 4:03 PM, Junio C Hamano wrote:
> Derrick Stolee <stolee@gmail.com> writes:
> 
>> Thanks for double-checking. I also think that dropping the
>> "hide the error" patch is prudent.
> 
> Thanks again for a quick and straight-forward fix.  As I mentioned
> elsewhere in the thread, it appears that we invented duplicate API
> with parallel implementation in get_reachable_subset(), which seems
> to be a strict superset of in_merge_bases_many(), and that may be
> what led to an initial and incorrect "get_reachable_subset() is not
> broken the same way as in_merge_bases_many() so use it instead"
> response.  I haven't paid attention to the quality of implementation
> of get_reachable_subset() as much as in_merge_bases_many() (e.g. I
> know of an obvious way to optimize the latter) so far, but it would
> be wonderful if we can eventually rewrite in_merge_bases_many() as a
> very thin wrapper() around get_reachable_subset() without any
> downside.

I have self-assigned myself https://github.com/gitgitgadget/git/issues/740
which will investigate these duplicates and see what can be done.

I know that the initial refactoring focused on keeping the "public"
interface the same and just creating shims between different method
prototypes. In this case, it might be worth doing a full replacement
since in_merge_bases_many() has so few callers.

I'll be proactive to look for other cases that might be tricky for
new contributors to find the "right" way to do it.

Thanks,
-Stolee


  reply	other threads:[~2020-10-02 20:08 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-02 14:58 [PATCH] commit-reach: fix in_merge_bases_many bug Derrick Stolee via GitGitGadget
2020-10-02 15:59 ` Junio C Hamano
2020-10-02 18:51 ` Junio C Hamano
2020-10-02 19:47   ` Derrick Stolee
2020-10-02 20:03     ` Junio C Hamano
2020-10-02 20:08       ` Derrick Stolee [this message]
2020-10-02 20:03 ` Srinidhi Kaushik

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=ac3ac80d-7f8e-6b16-03fa-1cd38b5d860b@gmail.com \
    --to=stolee@gmail.com \
    --cc=derrickstolee@github.com \
    --cc=dstolee@microsoft.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=gitster@pobox.com \
    --cc=shrinidhi.kaushik@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.