feat: Support to set `git fetch` command options

[suzuki-shunsuke]

Similar to https://github.com/guitarrapc/git-shallow-clone-orb/issues/9 .

git fetch command supports some options about shallow clone such as --shallow-since.

       --deepen=<depth>
           Similar to --depth, except it specifies the number of commits from the current
           shallow boundary instead of from the tip of each remote branch history.

       --shallow-since=<date>
           Deepen or shorten the history of a shallow repository to include all reachable
           commits after <date>.

       --shallow-exclude=<revision>
           Deepen or shorten the history of a shallow repository to exclude commits
           reachable from a specified remote branch or tag. This option can be specified
           multiple times.

So I propose to add an optional option fetch_options. When the option fetch_options is set the parameter fetch_depth is ignored because --depth argument may conflict other arguments. If users want to set the depth parameter along with fetch_options, they can set --depth argument in fetch_options. --force option shouldn't be set in fetch_options because it is set automatically. And in case of a pull request, -t option is also set automatically.

What do you think?

Thank you.

[guitarrapc]

thank you for proposal. oh, dear, there are so many git arguments 💣

It is my favor but I believe adding more then 1 complex options/arguments, clone_options and fetch_options, will confuse user from "how to use this orb?".

Is it chance to offer 2 commands?

1. simple shallow-clone, as-is.
   • let's remove clone_options. breaking change
   • without eval requirement.
2. advanced shallow-clone, new!.
   • with clone_options & fetch_options.
   • include eval requirement as https://github.com/guitarrapc/git-shallow-clone-orb/pull/13#issuecomment-602592544 told.

[suzuki-shunsuke]

Thank you for your reply. Looks Good.

For the new command, maybe we can remove the parameter depth and fetch_depth.

So do you have any idea of new command name?

[guitarrapc]

may be adding some predictable word?

• checkout_shallow2 <- I don't like this pattern.
• checkout_shallow_advanced <- what advanced 😕
• checkout_shallow_with_options <- too long?
• checkout_shallow_ex <- hey. no 👎

remove checkout?

• shallow_with_options <- not predictable?

[suzuki-shunsuke]

This orb name is git-shallow-clone, so maybe shallow isn't needed in the command name.

[guitarrapc]

• checkout
• checkout_with_options
• checkout_advanced

[guitarrapc]

seems nice 👍

[guitarrapc]

• checkout_dander_options

supporting each options is match safer but too annoying.

[guitarrapc]

description should indicate user that eval is used? no?

all code is open on orb registry, user can check what's going on. <- hey it's bash, who want to read :-p

description is enough?

[guitarrapc]

on this stage,

https://github.com/guitarrapc/git-shallow-clone-orb/issues/12#issuecomment-602659755

I consider as...

• simple shallow-clone will be fit for 99% use case.
• eval can be used in advanced, with description explain eval is used.
  • for users who really require to avoid risk will use their command with dedicated parameter.

I believe it's make sence.

[guitarrapc]

command names.

• checkout
• checkout_advanced

[guitarrapc]

changes are included in #14 .

[guitarrapc]

released 2.0.0 include this change. https://github.com/guitarrapc/git-shallow-clone-orb/releases/tag/v2.0.0

https://circleci.com/orbs/registry/orb/guitarrapc/git-shallow-clone?version=2.0.0