public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Daisuke Fujimura <booleanlabel@gmail.com>
To: cygwin-apps@cygwin.com
Subject: Re: [PATCH cygport] git.cygclass: Suppress the depth option
Date: Thu, 30 Nov 2023 21:17:11 +0900	[thread overview]
Message-ID: <CAA3frXQZObO7EaKXWnmeaNS6uiqE-X+fbcyrhJndAUEUNfhnzg@mail.gmail.com> (raw)
In-Reply-To: <c23fcb07-2b71-42e5-8f5c-39dfe7bf042b@dronecode.org.uk>

Implementations that conditionally branch on variables are simple.

The proposed retry implementation complicates git.cygclass, but I
think it reduces the maintainer's effort.

I have created a patch for a retry implementation.
Could you review it?

diff --git a/cygclass/git.cygclass b/cygclass/git.cygclass
index e53a7985..1e26ab37 100644
--- a/cygclass/git.cygclass
+++ b/cygclass/git.cygclass
@@ -76,19 +76,33 @@ git_fetch() {
  # (not allowed for a hash, unless remote is configured to permit
  # it with allow*SHA1InWant).
  _depth="--depth 1"
+ _branch=""
  if defined GIT_TAG
  then
- _depth+=" --branch ${GIT_TAG}"
+ _depth=" --branch ${GIT_TAG}"
  elif defined GIT_BRANCH
  then
- _depth+=" --branch ${GIT_BRANCH}"
+ _depth=" --branch ${GIT_BRANCH}"
  fi
  fi

  # T likely doesn't exist at this point, so create it first
  mkdir -p ${T}
  cd ${T}
- verbose git clone ${_depth} --no-checkout ${GIT_URI} ${GIT_MODULE}
|| error "git clone failed"
+ _gitlog=${T}/git.$$.log
+ verbose git clone ${_depth} ${_branch} --no-checkout ${GIT_URI}
${GIT_MODULE} |& tee ${_gitlog}
+ if [ ${PIPESTATUS[0]} != 0 ]
+ then
+ grep "fatal: dumb http transport does not support shallow
capabilities" ${_gitlog} >& /dev/null
+ if [ $? = 0 ]
+ then
+ warning "git clone failed, retry without --depth option"
+ verbose git clone ${_branch} --no-checkout ${GIT_URI} ${GIT_MODULE}
|| error "git clone failed"
+ else
+ error "git clone failed"
+ fi
+ fi
  cd ${T}/${GIT_MODULE}

 #****v* git.cygclass/GIT_BRANCH


On Mon, Nov 20, 2023 at 11:23 PM Jon Turney <jon.turney@dronecode.org.uk> wrote:
>
> On 19/11/2023 02:11, Daisuke Fujimura via Cygwin-apps wrote:
> > Some git providers do not support smart transport, so specifying the
> > depth option will result in an error.
>
> Right. This is a bug and needs fixing.
>
> Thanks for the patch.
>
> > ```
> > Cloning into 'xxxx'...
> > fatal: dumb http transport does not support shallow capabilities
> > ```
> >
> > Therefore, I suggest adding a variable to suppress the depth option.
> > (Variable names should be changed to something appropriate according
> > to the naming convention.)
> >
> > diff --git a/cygclass/git.cygclass b/cygclass/git.cygclass
> > index e53a7985..0aa97a09 100644
> > --- a/cygclass/git.cygclass
> > +++ b/cygclass/git.cygclass
> > @@ -75,7 +75,12 @@ git_fetch() {
> > # shallow fetch a ref (master, branch or tag) with --depth=1
> > # (not allowed for a hash, unless remote is configured to permit
> > # it with allow*SHA1InWant).
> > - _depth="--depth 1"
> > + _depth=""
> > + # git provider does not support smart transport
> > + if ! defined GIT_PROVIDER_NOT_SUPPORT_SMART_TRANSPORT
>
> If you're going to add a variable which changes the behaviour of cygport
> like this, it should be documented (by adding an appropriate robodoc
> comment)
>
> This could just be named something a little shorter, like
> "GIT_URI_NO_SMART_TRANSPORT", since it's really a property of the URI's
> host?
>
> But I wonder if wouldn't just be better to try with --depth and then
> fallback to without it, if that fails (especially if we can tell it
> failed for that reason).
>
> (Looking at [1], that seems a better approach than trying to probe the
> URI for smart transport support, which seems problematic)
>
> [1]
> https://stackoverflow.com/questions/9270488/is-it-possible-to-detect-whether-a-http-git-remote-is-smart-or-dumb
>
> What do you think?
>
> > + then
> > + _depth="--depth 1"
> > + fi
> > if defined GIT_TAG
> > then
> > _depth+=" --branch ${GIT_TAG}"
> >
>

  parent reply	other threads:[~2023-11-30 12:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-19  2:11 Daisuke Fujimura
2023-11-20 14:23 ` Jon Turney
2023-11-20 16:42   ` ASSI
2023-11-30 12:17   ` Daisuke Fujimura [this message]
2023-12-03 20:34     ` Jon Turney
2023-12-03 21:53       ` Brian Inglis
2023-12-16 15:38         ` Daisuke Fujimura
2024-01-13 14:49           ` Jon Turney
2024-02-11 17:09         ` Jon Turney
2024-02-16 11:59           ` Daisuke Fujimura
2024-02-18 15:10             ` Jon Turney

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=CAA3frXQZObO7EaKXWnmeaNS6uiqE-X+fbcyrhJndAUEUNfhnzg@mail.gmail.com \
    --to=booleanlabel@gmail.com \
    --cc=cygwin-apps@cygwin.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).