Hi,
This is a series to customize Git's behavior when listing references
from an alternate repository. It is motivated by the following example:
Consider an upstream repository, a fork of it, and a local copy of that
fork. Ideally, running "git pull upstream" from the local copy followed
by a "git push fork" should be a lightweight operation, ideally because
the fork already "knows" about the new objects introduced upstream.
Today, we do this by means of the special ".have" references advertised
by 'git receive-pack'. This special part of the advertisement is
designed to tell the pusher about tips that it might want to know about,
to avoid sending them again.
This optimization is a good one and works well, particularly when the
upstream repository has a relatively normal number of references. When
the upstream has a pathologically _large_ number of references, the
advertisement alone can be so time consuming, that it's faster to send
redundant objects to the fork.
To make the reference advertisement manageable even with a large number
of references, let's allow the fork to select which ones it thinks might
be "interesting", and only advertise those. This makes the advertisement
much smaller, and lets us take advantage of the ".have" references, even
when the upstream contains more references than we're advertising.
This series implements the above functionality by means of
"core.alternateRefsCommand", and "core.alternateRefsPrefixes", either a
command to run in place of "git for-each-ref", or arguments to be
appended to "git for-each-ref".
The order of precedence when listing references from an alternate is as
follows:
1. If the fork configures "core.alternateRefsCommand", run that.
2. If the fork configures "core.alternateRefsPrefixes", run 'git
for-each-ref', limiting results to references that have any of the
given values as a prefix.
3. Otherwise, run 'git for-each-ref' in the alternate.
In a previous version of this series, I taught the configuration
property to the alternate, as in "these are the references that _I_
think _you_ will find interesting," rather than the other way around. I
ultimately decided on what is attached here so that the fork does not
have to trust the upstream to run arbitrary shell commands.
Thanks,
Taylor
Taylor Blau (3):
transport.c: extract 'fill_alternate_refs_command'
transport.c: introduce core.alternateRefsCommand
transport.c: introduce core.alternateRefsPrefixes
Documentation/config.txt | 12 +++++++++
t/t5410-receive-pack.sh | 58 ++++++++++++++++++++++++++++++++++++++++
transport.c | 34 ++++++++++++++++++-----
3 files changed, 98 insertions(+), 6 deletions(-)
create mode 100755 t/t5410-receive-pack.sh
--
2.19.0
