On Wednesday 16 July 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> > Okay, it seems like I never have time to review this, so I'll just
> >
> > take a few minutes to comment on some aspects:
> >> @@ -1094,6 +1104,8 @@ int cmd_cherry(int argc, const char **argv,
> >> const char *prefix)
> >> const char *limit = NULL;
> >> int verbose = 0;
> >>
> >> + git_config(git_cherry_config, NULL);
> >> +
> >> if (argc > 1 && !strcmp(argv[1], "-v")) {
> >> verbose = 1;
> >> argc--;
> >
> > Is this really purely for cherry, and not at all for "log
> > --cherry-pick"? Maybe it should be "cache.patchIds" to begin with.
>
> What other things would we want caches for?
This should be fairly obvious:
- git-notes (uses sha1-to-sha1 cache for storing commit-to-note
relationship)
- integrated bug trackers (uses sha1-to-sha1 cache for storing
commit-to-bugreport (or similar) relationships)
- ...any other mechanism that want to quickly map from a git object to some
associated data
There are probably plenty more ideas and use cases if people start looking.
AFAICS, each different use case would keep its cache in a separate file.
For local-repo-only caches the cache is kept within $GIT_DIR, and for shared
caches (IF that makes sense in any of the use cases) the cache could be
located in the working tree (either as a .git_foo file on relevant
branches, or as a file on a separate domain-specific branch).
Have fun! :)
...Johan
--
Johan Herland, <johan@xxxxxxxxxxx>
www.herland.net
--
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
