Re: [PATCH 2/2] ci(check-whitespace): restrict to the intended commits

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

 



Hi Taylor,

On Wed, 14 Jul 2021, Taylor Blau wrote:

> On Wed, Jul 14, 2021 at 03:25:15PM -0700, Junio C Hamano wrote:
> > "Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx>
> > writes:
> >
> > > Unfortunately, this means that we no longer can rely on a shallow clone:
> > > There is no way of knowing just how many commits the upstream branch
> > > advanced after the commit from which the PR branch branched off. So
> > > let's just go with a full clone instead, and be safe rather than sorry
> > > (if we have "too shallow" a situation, a commit range `@{u}..` may very
> > > well include a shallow commit itself, and the output of `git show
> > > --check <shallow>` is _not_ pretty).
> >
> > Makes sense.
> >
> > As long as you have pull-request base, I suspect that you could
> > shallow clone the base and incrementally fetch the rest to update,
> > perhaps?  But I do not know if it is worth doing so for a small
> > project like ours.
>
> Agreed, and...
>
> > >      - uses: actions/checkout@v2
> > >        with:
> > > -        fetch-depth: ${{ env.COMMIT_DEPTH }}
> > > +        fetch-depth: 0
>
> ...I wondered whether "fetch-depth: 0" was the default and whether or
> not this hunk could have just removed "fetch-depth" entirely. But the
> default is "1", and "0" means "fetch everything". So we really do need
> it.

Indeed. One of the things that makes `action/checkout@v2` so much faster
than `@v1` is that it fetches shallow by default. But we can't have that
here.

Ciao,
Dscho




[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