On Wed, Apr 1, 2015 at 1:31 PM, Junio C Hamano <[email protected]> wrote: > The only way a bundle can record "something" "noting" that it is an > incomplete history, while allowing it to be read by existing > implementations of "git bundle unbundle" is to list the commits, > behind which there is no history available in the bundle, as > bundle's pre-requisites. I said that the addition of shallow repository > support did not enhance "git bundle create" to do so, and you are > saying "it just needs to put", implying that it currently does not.
Alternatively, we can record SHA-1 in the shallow file as refs whose name is always ".shallow". This way "unbundle" can recreate the shallow file if it wants. Having this "remote" shallow file would fit well in our fetch pipeline. It's harder to recreate shallow file if we record prerequisite instead: if commit A is in the shallow file, the ones in prerequisite category would be A's parents. So we would need to go over the bundle to look for commits whose parents are all in prerequisite list. It takes more time. > Now, the only way the existing implementations of "git bundle > unbundle" can extract from such a bundle with prerequisites is to > unbundle into a repository that satisifies the prerequisites (these > incomplete bundle files are designed as a medium for sneaker-net > incremental updates). I however suspect "git clone --shallow" from > such a bundle _might_ work (I never tried it), but I wouldn't be > surprised if the existing implementations of bundle unpacking code > refused to unbundle into a repository that lacks prerequiste commits > (i.e. making the repository a shallow-clone). -- Duy -- 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
