git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 1/6 (v4)] man page and technical discussion for rev-cache

From
Nicolas Pitre <nico@cam.org>
Date
Aug 18, 2009, 02:34 UTC
Message-ID
<alpine.LFD.2.00.0908172227040.6044@xanadu.home>
In-Reply-To
<op.uys3qgmitdk399@sirnot.private>
On Mon, 17 Aug 2009, Nick Edelen wrote:
Show 5 quoted lines
> 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
[...]
Show 14 quoted lines
> +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?
Show 14 quoted lines
> +\--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
Previous: Nick EdelenNext: Nick Edelen
Message 2 of 8 in “man page and technical discussion for rev-cache”
  1. 1/6 man page and technical discussion for rev-cacheNick Edelen, Aug 17, 2009
  2. Nicolas PitreAug 18, 2009
  3. Nick EdelenAug 18, 2009
  4. Nick EdelenAug 21, 2009
  5. Junio C HamanoAug 21, 2009
  6. Nick EdelenSep 7, 2009
  7. Nick EdelenOct 2, 2009
  8. Nick EdelenOct 19, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.