Christian Couder <christian.couder@xxxxxxxxx> writes: > +Islands are configured via the `pack.island` option, which can be > +specified multiple times. Each value is a left-anchored regular > +expressions matching refnames. For example: > + > +------------------------------------------- > +[pack] > +island = refs/heads/ > +island = refs/tags/ > +------------------------------------------- > + > +puts heads and tags into an island (whose name is the empty string; see > +below for more on naming). Any refs which do not match those regular > +expressions (e.g., `refs/pull/123`) is not in any island. Any object > +which is reachable only from `refs/pull/` (but not heads or tags) is > +therefore not a candidate to be used as a base for `refs/heads/`. > + > +Refs are grouped into islands based on their "names", and two regexes > +that produce the same name are considered to be in the same island. The > +names are computed from the regexes by concatenating any capture groups > +from the regex (and if there are none, then the name is the empty > +string, as in the above example). This allows you to create arbitrary > +numbers of islands. For example, imagine you store the refs for each > +fork in `refs/virtual/ID`, where `ID` is a numeric identifier. You might > +then configure: > + > +------------------------------------------- > +[pack] > +island = refs/virtual/([0-9]+)/heads/ > +island = refs/virtual/([0-9]+)/tags/ > +island = refs/virtual/([0-9]+)/(pull)/ > +------------------------------------------- It becomes clear only from this example that what the feature calls (and documented in patch 2/5) "regexp" is not BRE but ERE. Update 2/5 so that it is clear to readers of "git config --help" who looks for "pack.island" in the output. > +That puts the heads and tags for each fork in their own island (named > +"1234" or similar), and the pull refs for each go into their own > +"1234-pull". "by concatenating any capture groups" made me imagine that the last one would be "1234pull" without dash. The actual rule should be mentioned in that paragraph (i.e. "concatenating any capture groups from the regex, with a '-' dash in between" or something like that). > +Note that we pick a single island for each regex to go into, using "last > +one wins" ordering (which allows repo-specific config to take precedence > +over user-wide config, and so forth).
