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

Re: [PATCH] fix simple deepening of a repo

From
Junio C Hamano <gitster@pobox.com>
Date
Aug 26, 2009, 09:03 UTC
Message-ID
<7vk50reykp.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20090826082256.GO1033@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 18 quoted lines
>> How will this mesh with 'git clone --mirror'?
>
> Not well.
>
>> Is the client expected to
>> ask with 'expand refs/*'?
>
> If the client is new enough to understand the "expand" extension,
> yes, it would ask for "expand refs/*" and get everthing, allowing
> it to complete a full mirror.
>
> If the client is older and doesn't know this extension, then it
> is hopeless.  The server isn't advertising refs/*, doesn't know
> that the client can't ask for refs/*, and the client doesn't know
> it is missing refs when it makes the mirror.
>
> This backwards incompatible breakage is something I have no real
> solution for.  :-|

But we at least can assume that the server operator is reasonable and wouldn't go overboard, (ab)using this "abbreviated advertisement" feature to hide heads and tags from the clients. I would suspect that a server operated by such a sick person who hides these normal refs will be shunned by users so it won't either happen in practice, or even if it happens, it won't be a problem---simply because nobody would want to interact with such a server.

Think about in what situation you would want to do a mirror clone. The most obvious is to have a back-up or secondary distribution point, and I do not think of any other sane reason (other than "because I can", which does not count). If the original repository has so many refs to benefit from the "abbreviated advertisement" feature (otherwise there is no point using it in the first place), then its mirror repository would also want to use the feature when talking to its clients, acting as a back-up distribution point. That means the version of git used to prime, update and serve the mirror will know the expand extention.

I am hoping that we can finish 1.6.5 by mid September (let's tentatively say we will shoot for 16th). I expect the expand extention to be in 'next' by that time, cooking for 1.7.0. How does that timetable sound?

Previous: Shawn O. PearceNext: Shawn O. Pearce
Message 19 of 22 in “git fetch --depth=* broken?”
  1. Nicolas PitreAug 22, 2009
  2. fix simple deepening of a repoNicolas Pitre, Aug 24, 2009
  3. Junio C HamanoAug 24, 2009
  4. Nicolas PitreAug 24, 2009
  5. Johan HerlandAug 24, 2009
  6. Junio C HamanoAug 24, 2009
  7. Daniel BarkalowAug 24, 2009
  8. Julian PhillipsAug 24, 2009
  9. Nicolas PitreAug 25, 2009
  10. Shawn O. PearceAug 25, 2009
  11. Sverre RabbelierAug 25, 2009
  12. Junio C HamanoAug 25, 2009
  13. Shawn O. PearceAug 25, 2009
  14. Junio C HamanoAug 25, 2009
  15. Shawn O. PearceAug 25, 2009
  16. Shawn O. PearceAug 26, 2009
  17. Johannes SixtAug 26, 2009
  18. Shawn O. PearceAug 26, 2009
  19. Junio C HamanoAug 26, 2009
  20. Shawn O. PearceAug 26, 2009
  21. upload-pack: expand capability advertises additional refsShawn O. Pearce, Aug 28, 2009
  22. Junio C HamanoAug 28, 2009

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.