Re: [PATCH v2] clarify documentation for remote helpers

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

 



On Fri, 30 Aug 2019 at 16:00, David Turner <dturner@xxxxxxxxxxxx> wrote:
>
> Signed-off-by: David Turner <dturner@xxxxxxxxxxxx>
> ---
>  Documentation/gitremote-helpers.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gitremote-helpers.txt b/Documentation/gitremote-helpers.txt
> index 43f80c8068..f4a165387f 100644
> --- a/Documentation/gitremote-helpers.txt
> +++ b/Documentation/gitremote-helpers.txt
> @@ -297,9 +297,9 @@ Supported if the helper has the "option" capability.
>         same batch are complete. Only objects which were reported
>         in the output of 'list' with a sha1 may be fetched this way.
>  +
> -Optionally may output a 'lock <file>' line indicating a file under
> -GIT_DIR/objects/pack which is keeping a pack until refs can be
> -suitably updated.
> +Optionally may output a 'lock <file>' line indicating the full path of
> +a file under $GIT_DIR/objects/pack which is keeping a pack until refs

I'd still like to suggest backticks: `$GIT_DIR/objects/pack`

> +can be suitably updated.  The path must end with ".keep".
>  +
>  If option 'check-connectivity' is requested, the helper must output
>  'connectivity-ok' if the clone is self-contained and connected.

Here's how I interpret the motivation behind the patch:

  Reading the text on the optional 'lock <file>' line, it's easy to
  believe that the filename should be given relative to
  $GIT_DIR/objects/pack. Actually, one needs to provide the full path.
  Also, we fail to mention that the filename must end with ".pack".

But I'd have to take your word for these two claims, since I haven't
actually tested or dug myself. ;-)

I do wonder... If we're giving a full path which points outside of
$GIT_DIR/objects/pack, what will happen? Will /mnt/my-packs/foo.pack
work just as fine? If yes, then I don't see a reason to mention
$GIT_DIR/objects/pack at all. If no, it sort of begs the question of why
we don't accept relative filenames. (Or mandate them, but that boat has
obviously sailed.) Either way, I'm wondering if there isn't a bug left
here. What do you think?

Martin



[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