Jamey Sharp <jamey@xxxxxxxxxxx> writes: > Given many repositories with copies of the same objects (such as > branches of the same source), sharing a common object store will avoid > duplication. Alternates provide a single baseline, but don't handle > ongoing activity in the various repositories. Git safely handles > concurrent accesses to the same object store across repositories, but > operations such as gc need to know about all of the refs. > > This change adds support in upload-pack and receive-pack to simulate > multiple virtual repositories within the object store and references of Is it just me to read the above and then have to re-read the first sentence of the second paragraph over and over again? There seems to be a huge gap in logic flow, probably largely due to the use of undefined term "virtual repository". I think the idea is "an object store .git/objects/ may have more objects than the refs .git/refs/* in the repository that particular object store belongs to, and it is unsafe to gc there" (the first paragraph), and then what is left unsaid is "to solve it, we propose to add an extra namespace in the refs hierarchy of such a repository that lets other repositories to borrow its objects from, and store the tips of refs of the borrowing repository there (and call such a repository that lets others borrow a virtual repository)" or something. Without presenting what you are trying to solve... > a single underlying repository. The refs and heads of the virtual > repositories get stored in the underlying repository using prefixed > names specified by the --ref-prefix and --head options; for instance, > --ref-prefix=repo1/ will use refs/repo1/heads/* and refs/repo1/tags/*. > upload-pack and receive-pack will not expose any references that do not > match the specified prefix. > > These options implement the underlying mechanism for virtual > repositories; the higher-level protocol handler (such as http-backend or > a custom server) can pass these options when invoking upload-pack or > receive-pack, providing values based on components of the repository > path. ... these are just gibberish describing technical details at too low-level. > For a simple local test, git-remote-ext works: > > git clone ext::'git %s --ref-prefix=prefix/ --head=prefix-HEAD /tmp/prefixed.git' > > Commit by Josh Triplett and Jamey Sharp. Have a blank line here, as that line is not part of Sign-of chain. > Signed-off-by: Josh Triplett <josh@xxxxxxxxxxxxxxxx> > Signed-off-by: Jamey Sharp <jamey@xxxxxxxxxxx> > Cc: Shawn O. Pearce <spearce@xxxxxxxxxxx> > Cc: Johannes Schindelin <Johannes.Schindelin@xxxxxx> > Cc: Johannes Sixt <johannes.sixt@xxxxxxxxxx> Also personally I do not appreciate seeing Cc: here. You already have them at the header of your e-mail; these lines belong there, not here. I haven't looked deeply at the patch yet. -- 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