git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH/RFC] remote-helper: allow fetch to discover sha1 later

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 14, 2012, 06:10 UTC
Message-ID
<7vmx0t6sod.fsf@alter.siamese.dyndns.org>
In-Reply-To
<1347531013-10371-1-git-send-email-djpohly@gmail.com>
"Devin J. Pohly" <djpohly@gmail.com> writes:
Show 10 quoted lines
> From: "Devin J. Pohly" <djpohly@gmail.com>
>
> Allow a fetch-style remote helper to issue the notification
>   ref <sha1> <name>
> to specify a ref's value during the fetch operation.
>
> Currently, a remote helper with the "fetch" capability cannot fetch a
> ref unless its sha1 was known when the "list" command was executed.
> This limitation is arbitrary, as the helper may eventually be able to
> determine the correct sha1 as it fetches objects.

While I am not fundamentally against supporting a remote helper that is not capable of saying what the object names of the tip of its histories are before doing a lot of work, I do not think it is a good idea to allow such a helper to claim that it supports "fetch" capability, for at least two reasons:

 * Being able to "list" is essential for "fetch" based helpers, I
   think, far from "arbitrary".  When running a "git fetch" against
   such a remote, we can first issue "list" to see what it has and
   avoid asking for the refs that point at the histories we already
   have (or the refs that are the same as the last time we fetched
   from the remote).  I do not offhand know if we do this kind of
   optimization, but if we don't, we should.
 * Existing versions of "git" that can drive remote helpers that
   claim to have "fetch" capability are not prepared to accept an
   unknown "refs" protocol message from the helper, so a helper
   written for your new semantics of "fetch" capability will not
   work with them.  The point of capability mechanism is to prevent
   such a compatibility issue from breaking the system, and this
   patch goes against that spirit.

Such a remote helper should not advertise to support "fetch" capability, because it does not support it. It can advertise that it supports "something else" and it is OK to make an updated Git that knows how to drive a remote helper that lack "fetch" but support that "something else" work with it.

Previous: Devin J. PohlyNext: Devin J. Pohly
Message 2 of 3 in “remote-helper: allow fetch to discover sha1 later”
  1. remote-helper: allow fetch to discover sha1 laterDevin J. Pohly, Sep 13, 2012
  2. Junio C HamanoSep 14, 2012
  3. Devin J. PohlySep 14, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.