Re: [BUGREPORT] Why is git-push fetching content?

From: Tao Klerks <tao@klerks.biz>
Date: Jun 20, 2023, 11:26 UTC
Message-ID: <CAPMMpoiC8oca0AVNy1f+zy26L_b-ADyNopY4zO3r+v6v-KEH=A@mail.gmail.com>
In-Reply-To: <m0pma14sbx.fsf@epic96565.epic.com>

On Wed, Feb 22, 2023 at 4:45 PM Sean Allred <allred.sean@gmail.com> wrote:

Show 11 quoted lines

>
>
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> > It's hard to know for certain what's going on here, but it depends on
> > your history.  You did a partial clone with no trees, so you've likely
> > received a single commit object and no trees or blobs.
>
> Yup, this was the intention behind `--depth=1 --filter=tree:0`. The
> server doing this ref update needs to be faster than having the full
> history would allow.
>

FWIW, you're not alone - we do exactly the same thing, for the same reasons, and get the same outcome: We want to create a tag in a CI job, that particular CI job has no reason to check out the code, all we know is we want ref XXXXX to point to commit YYYYY.

The most logical way to achieve that seems to be to do a shallow partial no-checkout clone of commit YYYYY, and then push to remote ref XXXXX, but the push ends up doing extra seemingly-unnecessary jit-fetching work.

In our case it's still better than any alternative we've found, but wastes a few seconds that we'd love to see optimized away.