[0/2] Symlink resolutions: limits and return modes

Message

Philippe Blain via GitGitGadget June 17, 2024, 9:03 a.m. UTC

It can be useful to limit the number of symlink resolutions performed while
looking for a tree entry. The goal is to provide the ability to resolve up
to a particular depth, instead of reaching the end of the link chain.

In addition, I would like to extend the symlink resolution process and
provide the ability to return the object found at the designated depth
instead of returning an error.

The current code already provides a limit to the maximum number of
resolutions that can be performed, and something similar to this is returned
to the caller:

loop SP <size> LF
<object> LF


With these patches, we are looking to return the actual information of the
object where the resolution stopped. Something similar to:

<oid> blob <size>\nndata\n


Miguel Ángel Pastor Olivar (2):
  cat-file: configurable number of symlink resolutions
  cat-file: configurable "best effort mode" for symlink resolution

 Documentation/config/core.txt | 19 +++++++++++++++
 config.c                      | 18 ++++++++++++++
 environment.c                 |  3 +++
 environment.h                 |  8 ++++++
 t/t1006-cat-file.sh           | 46 +++++++++++++++++++++++++++++++++++
 tree-walk.c                   | 18 +++++++++++++-
 6 files changed, 111 insertions(+), 1 deletion(-)


base-commit: d63586cb314731c851f28e14fc8012988467e2da
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-1751%2Fmigue%2Fmigue%2Ffollow-symlinks-max-depth-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-1751/migue/migue/follow-symlinks-max-depth-v1
Pull-Request: https://github.com/gitgitgadget/git/pull/1751

Comments

Junio C Hamano June 17, 2024, 7:33 p.m. UTC | #1

"Miguel Ángel Pastor Olivar via GitGitGadget"
<[e-mail]> writes:

> The current code already provides a limit to the maximum number of
> resolutions that can be performed, and something similar to this is returned
> to the caller:
>
> loop SP <size> LF
> <object> LF
>
>
> With these patches, we are looking to return the actual information of the
> object where the resolution stopped. Something similar to:
>
> <oid> blob <size>\nndata\n

Just a random and idle thought, but is it all that interesting to
learn only about the object at the horizon?

If recursive resolutions are limited to say 3 levels, I wonder if it
is beneficial to give full record from each iteration without losing
information, e.g., saying "A points at B which in turn points at C,
and I stopped there but C is still not the final thing", instead of
saying "I followed links and C was the last one I saw after I
repeated for the maximum number of times the configuration allows me
to".