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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 22, 2023 at 4:45 PM Sean Allred <allred.sean@xxxxxxxxx> wrote:
>
>
> "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> 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.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux