osc co scm_disturl does whole clone instead of shallow clone

[thackara]

Describe the bug

1. for scmsync enabled projects,
   osc co -r $rev $prj $pkg -o directory, does a whole clone instead of a shallow clone.
   -> OSC_VERSION is set in the script (which also sets the following in obs_scm_bridge, get_assets = True, shallow_clone = False), hence the whole clone.

2. also when out directory (-o directory) is provided, the following error is observed,
   Error: "CWD/$prj" is not an osc working copy.

Versions

• Operating system: openSUSE Tumbleweed
• Packages: osc-1.9.2

To Reproduce
Steps to reproduce the behavior:

1. osc co <scm_disturl>

Expected behavior

1. Shallow clone with osc co <scm_disturl>

Screenshots, console outputs
If applicable, add screenshots or console outputs to help explain your problem.

Additional context
Add any other context about the problem here.

[adrianschroeter]

It is true that the bridge behaves different when used with "osc co". The reason behind is that you most likely want to work on your code, being able to cherrypick, branch, whatever locally.
While on the server side the size and speed matters. We may also allow to do a deep clone there optionally in future though.

However, why is it an issue that you get a deep copy locally?

[thackara]

• @hramrach

why is it an issue that you get a deep copy locally?

Deep or Shallow,
with osc co --revision:
-r rev, --revision rev
checkout the specified revision. NOTE: if you checkout
the complete project this option is ignored!

osc co --revision tells us that We should expect only the revision (sources used to build that package) gets checked out. That isn't the case with git-based projects checkout (where the whole repository is deep cloned and also checked out to a HEAD which is the latest revision not the given revision)

Previous osc co -r (with maintenance-projects/ reproducible builds) used to checkout only the sources that were used to build that package (, a behavior that is same as doing shallow clone with a particular COMMIT_SHA). I think it's fair to expect the same behavior with git-based projects as well.

[hramrach]

These will be either temporary directories that are later removed or permanent directories one per branch. Not great but also should not cause a big problem while Micro is only small part of the built packages.

[hramrach]

So checking out whole history when one revision is requested wastes bandwidth and storage but is likely not a critical problem.

I am not aware of git support for sparse checkout of specific revision, only of specific branch. It might be trivial problem easily resolved by UI change but it might be also fundamental problem with how the algorithm for fetching data from remote servers works.