From: Phillip Wood <phillip.wood123@gmail.com>
To: Harald Nordgren <haraldnordgren@gmail.com>, phillip.wood@dunelm.org.uk
Cc: "D. Ben Knoble" <ben.knoble@gmail.com>,
Harald Nordgren via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH] branch: let --delete-merged find squash merged branches
Date: Fri, 9 Oct 2026 14:37:36 +0100 [thread overview]
Message-ID: <500a1b40-b877-4970-b279-f0a6fb42f810@gmail.com> (raw)
In-Reply-To: <CAHwyqnWkTvicU+U99j0MzzUUXeVnUj=FJJwUDR1F7DGk1hmtrA@mail.gmail.com>
Hi Harald
On 08/10/2026 19:42, Harald Nordgren wrote:
>> Even an efficient implementation is going to be a lot slower when it is
>> trying to find branches that have been squashed, so I think we probably
>> do want a way to turn it off. That's especially true in partial clones
>> where we'll have to download a bunch of blobs to do the squash
>> detection. So long as it isn't diabolically slow enabling it by default
>> is probably fine.
>
> A bit slower (depends on how much!) could be worth it for improved
> usability. This is not a command that users will run multiple times a
> day.
>
> I would hope we could have it on by default and add a flag to turn it
> off instead.
That's my hope too
> For partial or shallow clones, we should probably warn the user that
> detection won't be able to search the full history, and offer them to
> unshallow, etc. It's very reasonable that some parts are turned off,
> when the user doesn't want to hold the complete repo.
I've not really though much about shallow clones, but for partial clones
I think it is perfectly reasonable to go and fetch the blobs we need to
calculate the patch ids and warn in the documentation that it can be slow.
Thanks
Phillip
next prev parent reply other threads:[~2026-10-09 13:37 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-29 7:30 [PATCH] branch: let --delete-merged find squash merged branches Harald Nordgren via GitGitGadget
2026-09-29 7:46 ` Kristoffer Haugsbakk
2026-09-29 7:52 ` Harald Nordgren
2026-09-29 8:08 ` Kristoffer Haugsbakk
2026-09-29 11:18 ` D. Ben Knoble
2026-09-29 13:31 ` Kristoffer Haugsbakk
2026-09-29 11:26 ` D. Ben Knoble
2026-09-29 13:44 ` Harald Nordgren
2026-09-29 13:52 ` Harald Nordgren
2026-09-29 15:28 ` D. Ben Knoble
2026-09-29 18:34 ` Harald Nordgren
2026-10-04 9:54 ` Phillip Wood
2026-10-04 22:28 ` Harald Nordgren
2026-10-08 15:25 ` Phillip Wood
2026-10-08 18:42 ` Harald Nordgren
2026-10-09 8:16 ` Kristoffer Haugsbakk
2026-10-09 11:11 ` Harald Nordgren
2026-10-09 11:18 ` Harald Nordgren
2026-10-09 13:40 ` Phillip Wood
2026-10-09 13:37 ` Phillip Wood [this message]
2026-10-09 15:27 ` Harald Nordgren
2026-10-08 17:51 ` D. Ben Knoble
2026-10-09 13:34 ` Phillip Wood
2026-10-11 9:41 ` [PATCH v2 0/2] " Harald Nordgren via GitGitGadget
2026-10-11 9:41 ` [PATCH v2 1/2] " Harald Nordgren via GitGitGadget
2026-10-11 9:41 ` [PATCH v2 2/2] branch: add --no-squashed to skip the squash search Harald Nordgren via GitGitGadget
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=500a1b40-b877-4970-b279-f0a6fb42f810@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=ben.knoble@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=haraldnordgren@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
/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