On Mon, 17 Aug 2009, Nick Edelen wrote: > diff --git a/Documentation/git-rev-cache.txt b/Documentation/git-rev-cache.txt > new file mode 100644 > index 0000000..3479499 > --- /dev/null > +++ b/Documentation/git-rev-cache.txt [...] > +add > +~~~ > +Add revisions to the cache by creating a new cache slice. Reads a revision > +list from the command line, formatted as: `START START ... \--not END END ...` > + > +Options: > + > +\--all:: > + Include all refs in the new cache slice, like the \--all option in > + 'rev-list'. > + > +\--fresh:: > + Exclude everything already in the revision cache, analogous to > + \--incremental in 'pack-objects'. Why not using --incremental here as wel then? > +\--stdin:: > + Read newline-seperated revisions from the standard input. Use \--not > + to exclude commits, as on the command line. > + > +\--legs:: > + Ensure newly-generated cache slice has no partial ends. This means that > + no commit has partially cached parents, in that all its parents are > + cached or none of them are. > ++ > +\--legs will cause 'rev-cache' to expand potential slice end-points (creating > +"legs") until this condition is met, simplifying the cache slice structure. > +'rev-cache' itself does not care if a slice has legs or not, but the condition > +may reduce the required complexity of other applications that might use the > +revision cache. I'm not sure I understand this. As a user, should I care? Nicolas -- 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