summaryrefslogtreecommitdiff
path: root/contrib/examples/builtin-fetch--tool.c
AgeCommit message (Collapse)AuthorFilesLines
2015-08-10memoize common git-path "constant" filesLibravatar Jeff King1-2/+2
One of the most common uses of git_path() is to pass a constant, like git_path("MERGE_MSG"). This has two drawbacks: 1. The return value is a static buffer, and the lifetime is dependent on other calls to git_path, etc. 2. There's no compile-time checking of the pathname. This is OK for a one-off (after all, we have to spell it correctly at least once), but many of these constant strings appear throughout the code. This patch introduces a series of functions to "memoize" these strings, which are essentially globals for the lifetime of the program. We compute the value once, take ownership of the buffer, and return the cached value for subsequent calls. cache.h provides a helper macro for defining these functions as one-liners, and defines a few common ones for global use. Using a macro is a little bit gross, but it does nicely document the purpose of the functions. If we need to touch them all later (e.g., because we learned how to change the git_dir variable at runtime, and need to invalidate all of the stored values), it will be much easier to have the complete list. Note that the shared-global functions have separate, manual declarations. We could do something clever with the macros (e.g., expand it to a declaration in some places, and a declaration _and_ a definition in path.c). But there aren't that many, and it's probably better to stay away from too-magical macros. Likewise, if we abandon the C preprocessor in favor of generating these with a script, we could get much fancier. E.g., normalizing "FOO/BAR-BAZ" into "git_path_foo_bar_baz". But the small amount of saved typing is probably not worth the resulting confusion to readers who want to grep for the function's definition. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-04-07refs.h: rename the action_on_err constantsLibravatar Michael Haggerty1-1/+2
Given that these constants are only being used when updating references, it is inappropriate to give them such generic names as "DIE_ON_ERR". So prefix their names with "UPDATE_REFS_". Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-11Merge branch 'jc/merge-bases'Libravatar Junio C Hamano1-1/+1
Optimise the "merge-base" computation a bit, and also update its users that do not need the full merge-base information to call a cheaper subset. * jc/merge-bases: reduce_heads(): reimplement on top of remove_redundant() merge-base: "--is-ancestor A B" get_merge_bases_many(): walk from many tips in parallel in_merge_bases(): use paint_down_to_common() merge_bases_many(): split out the logic to paint history in_merge_bases(): omit unnecessary redundant common ancestor reduction http-push: use in_merge_bases() for fast-forward check receive-pack: use in_merge_bases() for fast-forward check in_merge_bases(): support only one "other" commit
2012-08-27in_merge_bases(): support only one "other" commitLibravatar Junio C Hamano1-1/+1
In early days of its life, I planned to make it possible to compute "is a commit contained in all of these other commits?" with this function, but it turned out that no caller needed it. Just make it take two commit objects and add a comment to say what these two functions do. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-30remove superfluous newlines in error messagesLibravatar Pete Wyckoff1-2/+2
The error handling routines add a newline. Remove the duplicate ones in error messages. Signed-off-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-03Change incorrect "remote branch" to "remote tracking branch" in C codeLibravatar Matthieu Moy1-1/+1
(Just like we did for documentation already) In the process, we change "non-remote branch" to "branch outside the refs/remotes/ hierarchy" to avoid the ugly "non-remote-tracking branch". The new formulation actually corresponds to how the code detects this case (i.e. prefixcmp(refname, "refs/remotes")). Also, we use 'remote-tracking branch' in generated merge messages (by merge an fmt-merge-msg). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-20Merge branch 'jn/help-everywhere'Libravatar Junio C Hamano1-0/+574
* jn/help-everywhere: (23 commits) diff --no-index: make the usage string less scary merge-{recursive,subtree}: use usagef() to print usage Introduce usagef() that takes a printf-style format Let 'git <command> -h' show usage without a git dir Show usage string for 'git http-push -h' Let 'git http-fetch -h' show usage outside any git repository Show usage string for 'git stripspace -h' Show usage string for 'git unpack-file -h' Show usage string for 'git show-index -h' Show usage string for 'git rev-parse -h' Show usage string for 'git merge-one-file -h' Show usage string for 'git mailsplit -h' Show usage string for 'git imap-send -h' Show usage string for 'git get-tar-commit-id -h' Show usage string for 'git fast-import -h' Show usage string for 'git check-ref-format -h' http-fetch: add missing initialization of argv0_path Show usage string for 'git show-ref -h' Show usage string for 'git merge-ours -h' Show usage string for 'git commit-tree -h' ... Conflicts: imap-send.c
2009-11-09Retire fetch--tool helper to contrib/examplesLibravatar Jonathan Nieder1-0/+574
When git-fetch was builtin-ized, the previous script was moved to contrib/examples. Now, it is the sole remaining user for 'git fetch--tool'. The fetch--tool code is still worth keeping around so people can try out the old git-fetch.sh, for example when investigating regressions from the builtinifaction. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>