On 2014-10-16 17:26, Marc Branchaud wrote:
I just don't see what difference the --borrow option makes. Consider the two
cases:
With just --reference=/local/pool/linux.git:
1. Set up the alternates file with that path.
x. Fetch object from origin not present in pool
2. Copy gko's refs into refs/remotes/origin/.
3. Set up refs/heads/master to refer to gko's HEAD.
4. Checkout refs/heads/master (uses objects from local pool).
With both that --reference and --borrow=../my/neighbour/linux-hack.git:
1. Set up the alternates file with both paths.
x. Fetch objects from origin not present in either pool
or neighbour repo ("have" pool and neighbour)
2. Copy gko's refs into refs/remotes/origin/.
3. Set up refs/heads/master to refer to gko's HEAD.
4. Checkout refs/heads/master (uses objects from local pool).
5. Disassociate ourselves from the neighbour repo.
which means roughly:
5.1. Remove neighbour repo from alternates
5.2. Fetch required objects from neighbour repo
("want" neighbour, have ???)
It is possible that because of technical limitations --reference and
--borrow / dissociate / --temporary-reference / --object-cache are to be
mutually exclusive.
In both cases the first four actions have no need of the neighbour repo. The
second case's fifth action surgically removes the neighbour as an alternate
object store, and we're left with the same clone we got in the first case.
What was the point?
You are missing fetching object from your list of actions.
It seems that in order to make something like --borrow useful, "git clone"
would somehow need to know which of the neighbour's refs you want to *also*
clone, then copy any unique objects from the neighbour before disassociating
from it.
M.
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html