Andrew Keller <[email protected]> writes:
> Okay, so to re-frame my idea, like you said, the goal is to find a user-
> friendly way for the user to tell git-clone to set up the alternates file
> (or perhaps just use the --alternates parameter), and run a repack,
> and disconnect the alternate. And yet, we still want to be able to use
> --reference on its own, because there are existing use cases for that.
Here are a few possible action items that came out of this
discussion:
1. Introduce a new "--borrow" option to "git clone".
The updates to the SYNOPSIS section may go like this:
-'git clone' [--reference <repository>] ...other options...
+'git clone' [[--reference|--borrow] <repository>] ...other options...
The new option can be used instead of "--reference" and they
will be mutually incompatible. The first implementation of the
"--borrow" option would do the following:
(1) run the same "git clone" with the same command line but
replacing "--borrow" with "--reference"; if this fails, exit
with the same failure.
(2) in the resulting repository, run "git repack -a -d"; if this
fails, remove the entire directory the first step created,
and exit with failure.
(3) remove .git/objects/info/alternates from the resulting
repository and exit with success.
and it may be acceptable as the final implementation as well.
2. Make "git repack" safer for the users of "clone --reference" who
want to keep sharing objects from the original.
- Introduce the "repack.local" configuration variable that can
be set to either true or false. Missing variable defaults to
"false".
- A "repack" that is run without "-l" option on the command line
will pretend as if it was given "-l" from the command line if
"repack.local" is set to "true". Add "repack --no-local"
option to countermand this configuration variable from the
command line.
- Teach "git clone --reference" (but not "git clone --borrow")
to set "repack.local = true" in the configuration of the
resulting repository.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
