path: root/builtin/rev-parse.c
AgeCommit message (Collapse)Author
2016-12-16Merge branch 'jk/rev-parse-symbolic-parents-fix'Junio C Hamano
"git rev-parse --symbolic" failed with a more recent notation like "HEAD^-1" and "HEAD^!". * jk/rev-parse-symbolic-parents-fix: rev-parse: fix parent shorthands with --symbolic
2016-11-16rev-parse: fix parent shorthands with --symbolicJeff King
The try_parent_shorthands() function shows each parent via show_rev(). We pass the correct parent sha1, but our "name" parameter still points at the original refname. So asking for a regular rev-parse works fine (it prints the sha1s), but asking for the symbolic name gives nonsense like: $ git rev-parse --symbolic HEAD^-1 HEAD ^HEAD which is always an empty set of commits. Asking for "^!" is likewise broken, with the added bonus that its prints ^HEAD for _each_ parent. And "^@" just prints HEAD repeatedly. Arguably it would be correct to just pass NULL as the name here, and always get the parent expressed as a sha1. The "--symbolic" documentaton claims only "as close to the original input as possible", and we certainly fallback to sha1s where necessary. But it's pretty easy to generate a symbolic name on the fly from the original. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-10-27Merge branch 'lt/abbrev-auto'Junio C Hamano
Allow the default abbreviation length, which has historically been 7, to scale as the repository grows. The logic suggests to use 12 hexdigits for the Linux kernel, and 9 to 10 for Git itself. * lt/abbrev-auto: abbrev: auto size the default abbreviation abbrev: prepare for new world order abbrev: add FALLBACK_DEFAULT_ABBREV to prepare for auto sizing
2016-10-03abbrev: prepare for new world orderJunio C Hamano
The code that sets custom abbreviation length, in response to command line argument, often does something like this: if (skip_prefix(arg, "--abbrev=", &arg)) abbrev = atoi(arg); else if (!strcmp("--abbrev", &arg)) abbrev = DEFAULT_ABBREV; /* make the value sane */ if (abbrev < 0 || 40 < abbrev) abbrev = ... some sane value ... However, it is pointless to sanity-check and tweak the value obtained from DEFAULT_ABBREV. We are going to allow it to be initially set to -1 to signal that the default abbreviation length must be auto sized upon the first request to abbreviate, based on the number of objects in the repository, and when that happens, rejecting or tweaking a negative value to a "saner" one will negatively interfere with the auto sizing. The codepaths for git rev-parse --short <object> git diff --raw --abbrev do exactly that; allow them to pass possibly negative abbrevs intact, that will come from DEFAULT_ABBREV in the future. Signed-off-by: Junio C Hamano <>
2016-09-27revision: new rev^-n shorthand for rev^n..revVegard Nossum
"git log rev^..rev" is commonly used to show all work done on and merged from a side branch. This patch introduces a shorthand "rev^-" for this and additionally allows "rev^-$n" to mean "reachable from rev, excluding what is reachable from the nth parent of rev". For example, for a two-parent merge, you can use rev^-2 to get the set of commits which were made to the main branch while the topic branch was prepared. Signed-off-by: Vegard Nossum <> Signed-off-by: Junio C Hamano <>
2016-08-01use strbuf_addstr() for adding constant strings to a strbufRené Scharfe
Replace uses of strbuf_addf() for adding strings with more lightweight strbuf_addstr() calls. In http-push.c it becomes easier to see what's going on without having to verfiy that the definition of PROPFIND_ALL_REQUEST doesn't contain any format specifiers. Signed-off-by: Rene Scharfe <> Reviewed-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-04-03Merge branch 'jk/rev-parse-local-env-vars'Junio C Hamano
The "--local-env-vars" and "--resolve-git-dir" options of "git rev-parse" failed to work outside a repository when the command's option parsing was rewritten in 1.8.5 era. * jk/rev-parse-local-env-vars: rev-parse: let some options run outside repository t1515: add tests for rev-parse out-of-repo helpers
2016-02-29rev-parse: let some options run outside repositoryJeff King
Once upon a time, you could use "--local-env-vars" and "--resolve-git-dir" outside of any git repository, but they had to come first on the command line. Commit 68889b4 (rev-parse: remove restrictions on some options, 2013-07-21) put them into the normal option-parsing loop, fixing the latter. But it inadvertently broke the former, as we call setup_git_directory() before starting that loop. We can note that those options don't care even conditionally about whether we are in a git repo. So it's fine if we simply wait to setup the repo until we see an option that needs it. However, there is one special exception we should make: historically, rev-parse will set up the repository and read config even if there are _no_ options. Some of the tests in t1300 rely on this to check "git -c $config" parsing. That's not mirroring real-world use, and we could tweak the test. But t0002 uses a bare "git rev-parse" to check "are we in a git repository?". It's plausible that real-world scripts are relying on this. So let's cover this case specially, and treat an option-less "rev-parse" as "see if we're in a repo". Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-02-24Merge branch 'nd/git-common-dir-fix'Junio C Hamano
"git rev-parse --git-common-dir" used in the worktree feature misbehaved when run from a subdirectory. * nd/git-common-dir-fix: rev-parse: take prefix into account in --git-common-dir
2016-02-13rev-parse: take prefix into account in --git-common-dirNguyễn Thái Ngọc Duy
Most of the time, get_git_common_dir() returns an absolute path so prefix is irrelevant. If it returns a relative path (e.g. from the main worktree) then prefixing is required. Noticed-by: Mike Hommey <> Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2016-01-15rev-parse: read parseopt spec with strbuf_getline()Junio C Hamano
"rev-parse --parseopt" specification is clearly text and we should anticipate that we may be fed CRLF lines. Signed-off-by: Junio C Hamano <>
2016-01-15strbuf: introduce strbuf_getline_{lf,nul}()Junio C Hamano
The strbuf_getline() interface allows a byte other than LF or NUL as the line terminator, but this is only because I wrote these codepaths anticipating that there might be a value other than NUL and LF that could be useful when I introduced line_termination long time ago. No useful caller that uses other value has emerged. By now, it is clear that the interface is overly broad without a good reason. Many codepaths have hardcoded preference to read either LF terminated or NUL terminated records from their input, and then call strbuf_getline() with LF or NUL as the third parameter. This step introduces two thin wrappers around strbuf_getline(), namely, strbuf_getline_lf() and strbuf_getline_nul(), and mechanically rewrites these call sites to call either one of them. The changes contained in this patch are: * introduction of these two functions in strbuf.[ch] * mechanical conversion of all callers to strbuf_getline() with either '\n' or '\0' as the third parameter to instead call the respective thin wrapper. After this step, output from "git grep 'strbuf_getline('" would become a lot smaller. An interim goal of this series is to make this an empty set, so that we can have strbuf_getline_crlf() take over the shorter name strbuf_getline(). Signed-off-by: Junio C Hamano <>
2015-11-20Remove get_object_hash.brian m. carlson
Convert all instances of get_object_hash to use an appropriate reference to the hash member of the oid member of struct object. This provides no functional change, as it is essentially a macro substitution. Signed-off-by: brian m. carlson <> Signed-off-by: Jeff King <>
2015-11-20Add several uses of get_object_hash.brian m. carlson
Convert most instances where the sha1 member of struct object is dereferenced to use get_object_hash. Most instances that are passed to functions that have versions taking struct object_id, such as get_sha1_hex/get_oid_hex, or instances that can be trivially converted to use struct object_id instead, are not converted. Signed-off-by: brian m. carlson <> Signed-off-by: Jeff King <>
2015-10-26use pop_commit() for consuming the first entry of a struct commit_listRené Scharfe
Instead of open-coding the function pop_commit() just call it. This makes the intent clearer and reduces code size. Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2015-07-15rev-parse --parseopt: allow [*=?!] in argument hintsIlya Bobyr
A line in the input to "rev-parse --parseopt" describes an option by listing a short and/or long name, optional flags [*=?!], argument hint, and then whitespace and help string. We did not allow any of the [*=?!] characters in the argument hints. The following input pair=key=value equals sign in the hint used to generate a help line like this: --pair=key <value> equals sign in the hint and used to expect "pair=key" as the argument name. That is not very helpful as we generally do not want any of the [*=?!] characters in the argument names. But we do want to use at least the equals sign in the argument hints. Update the parser to make long argument names stop at the first [*=?!] character. Add test case with equals sign in the argument hint and update the test to perform all the operations in test_expect_success matching the t/README requirements and allowing commands like ./ --run=1-2 to stop at the test case 2 without any further modification of the test state area. Signed-off-by: Ilya Bobyr <> Signed-off-by: Junio C Hamano <>
2015-05-25builtin/rev-parse: rewrite to take an object_id argumentMichael Haggerty
Signed-off-by: Michael Haggerty <> Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2015-05-25each_ref_fn: change to take an object_id parameterMichael Haggerty
Change typedef each_ref_fn to take a "const struct object_id *oid" parameter instead of "const unsigned char *sha1". To aid this transition, implement an adapter that can be used to wrap old-style functions matching the old typedef, which is now called "each_ref_sha1_fn"), and make such functions callable via the new interface. This requires the old function and its cb_data to be wrapped in a "struct each_ref_fn_sha1_adapter", and that object to be used as the cb_data for an adapter function, each_ref_fn_adapter(). This is an enormous diff, but most of it consists of simple, mechanical changes to the sites that call any of the "for_each_ref" family of functions. Subsequent to this change, the call sites can be rewritten one by one to use the new interface. Signed-off-by: Michael Haggerty <> Signed-off-by: brian m. carlson <> Signed-off-by: Junio C Hamano <>
2015-05-11Merge branch 'nd/multiple-work-trees'Junio C Hamano
A replacement for contrib/workdir/git-new-workdir that does not rely on symbolic links and make sharing of objects and refs safer by making the borrowee and borrowers aware of each other. * nd/multiple-work-trees: (41 commits) prune --worktrees: fix expire vs worktree existence condition t1501: fix test with split index t2026: fix broken &&-chain t2026 needs procondition SANITY git-checkout.txt: a note about multiple checkout support for submodules checkout: add --ignore-other-wortrees checkout: pass whole struct to parse_branchname_arg instead of individual flags git-common-dir: make "modules/" per-working-directory directory checkout: do not fail if target is an empty directory t2025: add a test to make sure grafts is working from a linked checkout checkout: don't require a work tree when checking out into a new one git_path(): keep "info/sparse-checkout" per work-tree count-objects: report unused files in $GIT_DIR/worktrees/... gc: support prune --worktrees gc: factor out gc.pruneexpire parsing code gc: style change -- no SP before closing parenthesis checkout: clean up half-prepared directories in --to mode checkout: reject if the branch is already checked out elsewhere prune: strategies for linked checkouts checkout: support checking out into a new working directory ...
2015-01-14standardize usage info string formatAlex Henrie
This patch puts the usage info strings that were not already in docopt- like format into docopt-like format, which will be a litle easier for end users and a lot easier for translators. Changes include: - Placing angle brackets around fill-in-the-blank parameters - Putting dashes in multiword parameter names - Adding spaces to [-f|--foobar] to make [-f | --foobar] - Replacing <foobar>* with [<foobar>...] Signed-off-by: Alex Henrie <> Reviewed-by: Matthieu Moy <> Signed-off-by: Junio C Hamano <>
2015-01-07Merge branch 'jc/merge-bases'Junio C Hamano
The get_merge_bases*() API was easy to misuse by careless copy&paste coders, leaving object flags tainted in the commits that needed to be traversed. * jc/merge-bases: get_merge_bases(): always clean-up object flags bisect: clean flags after checking merge bases
2014-12-01setup.c: support multi-checkout repo setupNguyễn Thái Ngọc Duy
The repo setup procedure is updated to detect $GIT_DIR/commondir and set $GIT_COMMON_DIR properly. The core.worktree is ignored when $GIT_COMMON_DIR is set. This is because the config file is shared in multi-checkout setup, but checkout directories _are_ different. Making core.worktree effective in all checkouts mean it's back to a single checkout. Helped-by: Johannes Sixt <> Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2014-12-01git_path(): be aware of file relocation in $GIT_DIRNguyễn Thái Ngọc Duy
We allow the user to relocate certain paths out of $GIT_DIR via environment variables, e.g. GIT_OBJECT_DIRECTORY, GIT_INDEX_FILE and GIT_GRAFT_FILE. Callers are not supposed to use git_path() or git_pathdup() to get those paths. Instead they must use get_object_directory(), get_index_file() and get_graft_file() respectively. This is inconvenient and could be missed in review (for example, there's git_path("objects/info/alternates") somewhere in sha1_file.c). This patch makes git_path() and git_pathdup() understand those environment variables. So if you set GIT_OBJECT_DIRECTORY to /foo/bar, git_path("objects/abc") should return /foo/bar/abc. The same is done for the two remaining env variables. "git rev-parse --git-path" is the wrapper for script use. This patch kinda reverts a0279e1 (setup_git_env: use git_pathdup instead of xmalloc + sprintf - 2014-06-19) because using git_pathdup here would result in infinite recursion: setup_git_env() -> git_pathdup("objects") -> .. -> adjust_git_path() -> get_object_directory() -> oops, git_object_directory is NOT set yet -> setup_git_env() I wanted to make git_pathdup_literal() that skips adjust_git_path(). But that won't work because later on when $GIT_COMMON_DIR is introduced, git_pathdup_literal("objects") needs adjust_git_path() to replace $GIT_DIR with $GIT_COMMON_DIR. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2014-10-30get_merge_bases(): always clean-up object flagsJunio C Hamano
The callers of get_merge_bases() can choose to leave object flags used during the merge-base traversal by passing cleanup=0 as a parameter, but in practice a very few callers can afford to do so (namely, "git merge-base"), as they need to compute merge base in preparation for other processing of their own and they need to see the object without contaminate flags. Change the function signature of get_merge_bases_many() and get_merge_bases() to drop the cleanup parameter, so that the majority of the callers do not have to say ", 1" at the end. Give a new get_merge_bases_many_dirty() API to support only a few callers that know they do not need to spend cycles cleaning up the object flags. Signed-off-by: Junio C Hamano <>
2014-09-19refs: make rev-parse --quiet actually quietDavid Aguilar
When a reflog is deleted, e.g. when "git stash" clears its stashes, "git rev-parse --verify --quiet" dies: fatal: Log for refs/stash is empty. The reason is that the get_sha1() code path does not allow us to suppress this message. Pass the flags bitfield through get_sha1_with_context() so that read_ref_at() can suppress the message. Use get_sha1_with_context1() instead of get_sha1() in rev-parse so that the --quiet flag is honored. Signed-off-by: David Aguilar <> Signed-off-by: Junio C Hamano <>
2014-09-02Merge branch 'rs/strbuf-getcwd'Junio C Hamano
Reduce the use of fixed sized buffer passed to getcwd() calls by introducing xgetcwd() helper. * rs/strbuf-getcwd: use strbuf_add_absolute_path() to add absolute paths abspath: convert absolute_path() to strbuf use xgetcwd() to set $GIT_DIR use xgetcwd() to get the current directory or die wrapper: add xgetcwd() abspath: convert real_path_internal() to strbuf abspath: use strbuf_getcwd() to remember original working directory setup: convert setup_git_directory_gently_1 et al. to strbuf unix-sockets: use strbuf_getcwd() strbuf: add strbuf_getcwd()
2014-08-26use xgetcwd() to get the current directory or dieRené Scharfe
Convert several calls of getcwd() and die() to use xgetcwd() instead. This way we get rid of fixed-size buffers (which can be too small depending on the used file system) and gain consistent error messages. Signed-off-by: Rene Scharfe <> Signed-off-by: Junio C Hamano <>
2014-07-28Merge branch 'jk/misc-fixes-maint'Junio C Hamano
* jk/misc-fixes-maint: apply: avoid possible bogus pointer fix memory leak parsing core.commentchar transport: fix leaks in refs_from_alternate_cb free ref string returned by dwim_ref receive-pack: don't copy "dir" parameter
2014-07-24free ref string returned by dwim_refJeff King
A call to "dwim_ref(name, len, flags, &ref)" will allocate a new string in "ref" to return the exact ref we found. We do not consistently free it in all code paths, leading to small leaks. The worst is in get_sha1_basic, which may be called many times (e.g., by "cat-file --batch"), though it is relatively unlikely, as it only triggers on a bogus reflog specification. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-06-13rev-parse: add --shared-index-path to get shared index pathNguyễn Thái Ngọc Duy
Normally scripts do not have to be aware about split indexes because all shared indexes are in $GIT_DIR. A simple "mv $tmp_index $GIT_DIR/somewhere" is enough. Scripts that generate temporary indexes and move them across repos must be aware about split index and copy the shared file as well. This option enables that. Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2014-03-24rev-parse --parseopt: option argument name hintsIlya Bobyr
Built-in commands can specify names for option arguments when usage text is generated for a command. sh based commands should be able to do the same. Option argument name hint is any text that comes after [*=?!] after the argument name up to the first whitespace. Signed-off-by: Ilya Bobyr <> Signed-off-by: Junio C Hamano <>
2014-02-27Merge branch 'ds/rev-parse-required-args'Junio C Hamano
"git rev-parse --default" without the required option argument did not diagnose it as an error. * ds/rev-parse-required-args: rev-parse: check i before using argv[i] against argc
2014-01-28rev-parse: check i before using argv[i] against argcDavid Sharp
The --prefix, --default, and --resolve-git-dir options to git-rev-parse require an argument, but when given no argument, the code uses the NULL read from argv[argc] without checking, leading to a segfault. Instead, check first and die() with an error message. Signed-off-by: David Sharp <> Signed-off-by: Junio C Hamano <>
2013-12-27Merge branch 'jk/rev-parse-double-dashes'Junio C Hamano
"git rev-parse <revs> -- <paths>" did not implement the usual disambiguation rules the commands in the "git log" family used in the same way. * jk/rev-parse-double-dashes: rev-parse: be more careful with munging arguments rev-parse: correctly diagnose revision errors before "--"
2013-12-17Merge branch 'cc/starts-n-ends-with'Junio C Hamano
Remove a few duplicate implementations of prefix/suffix comparison functions, and rename them to starts_with and ends_with. * cc/starts-n-ends-with: replace {pre,suf}fixcmp() with {starts,ends}_with() strbuf: introduce starts_with() and ends_with() builtin/remote: remove postfixcmp() and use suffixcmp() instead environment: normalize use of prefixcmp() by removing " != 0"
2013-12-09rev-parse: be more careful with munging argumentsJeff King
When rev-parse looks at whether an argument like "" or "foobar^@" is a difference or parent-shorthand, it internally munges the arguments so that it can pass the individual rev arguments to get_sha1(). However, we do not consistently un-munge the result. For cases where we do not match (e.g., "doesnotexist..HEAD"), we would then want to try to treat the argument as a filename. try_difference gets() this right, and always unmunges in this case. However, try_parent_shorthand() never unmunges, leading to incorrect error messages, or even incorrect results: $ git rev-parse foobar^@ foobar fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' $ >foobar $ git rev-parse foobar^@ foobar For cases where we do match, neither function unmunges. This does not currently matter, since we are done with the argument. However, a future patch will do further processing, and this prepares for it. In addition, it's simply a confusing interface for some cases to modify the const argument, and others not to. Signed-off-by: Jeff King <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2013-12-09rev-parse: correctly diagnose revision errors before "--"Jeff King
Rev-parse understands that a "--" may separate revisions and filenames, and that anything after the "--" is taken as-is. However, it does not understand that anything before the token must be a revision (which is the usual rule implemented by the setup_revisions parser). Since rev-parse prefers revisions to files when parsing before the "--", we end up with the correct result (if such an argument is a revision, we parse it as one, and if it is not, it is an error either way). However, we misdiagnose the errors: $ git rev-parse foobar -- >/dev/null fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git <command> [<revision>...] -- [<file>...]' $ >foobar $ git rev-parse foobar -- >/dev/null fatal: bad flag '--' used after filename In both cases, we should know that the real error is that "foobar" is meant to be a revision, but could not be resolved. Signed-off-by: Jeff King <> Reviewed-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2013-12-05replace {pre,suf}fixcmp() with {starts,ends}_with()Christian Couder
Leaving only the function definitions and declarations so that any new topic in flight can still make use of the old functions, replace existing uses of the prefixcmp() and suffixcmp() with new API functions. The change can be recreated by mechanically applying this: $ git grep -l -e prefixcmp -e suffixcmp -- \*.c | grep -v strbuf\\.c | xargs perl -pi -e ' s|!prefixcmp\(|starts_with\(|g; s|prefixcmp\(|!starts_with\(|g; s|!suffixcmp\(|ends_with\(|g; s|suffixcmp\(|!ends_with\(|g; ' on the result of preparatory changes in this series. Signed-off-by: Christian Couder <> Signed-off-by: Junio C Hamano <>
2013-12-05Merge branch 'jc/ref-excludes'Junio C Hamano
People often wished a way to tell "git log --branches" (and "git log --remotes --not --branches") to exclude some local branches from the expansion of "--branches" (similarly for "--tags", "--all" and "--glob=<pattern>"). Now they have one. * jc/ref-excludes: rev-parse: introduce --exclude=<glob> to tame wildcards rev-list --exclude: export add/clear-ref-exclusion and ref-excluded API rev-list --exclude: tests document --exclude option revision: introduce --exclude=<glob> to tame wildcards
2013-11-01rev-parse: introduce --exclude=<glob> to tame wildcardsJunio C Hamano
Teach "rev-parse" the same "I'm going to glob, but omit the ones that match these patterns" feature as "rev-list". Signed-off-by: Junio C Hamano <>
2013-10-31rev-parse --parseopt: add the --stuck-long modeNicolas Vigier
Add the --stuck-long option to output the options in their long form if available, and with their arguments stuck. Contrary to the default form (non stuck arguments and short options), this can be parsed unambiguously when using options with optional arguments : - in the non stuck form, when an option is taking an optional argument you cannot know if the next argument is its optional argument, or the next option. - the long options form allows to differentiate between an empty argument '--option=' and an unset argument '--option', which is not possible with short options. Signed-off-by: Nicolas Vigier <> Signed-off-by: Junio C Hamano <>
2013-09-04Merge branch 'sb/parseopt-boolean-removal'Junio C Hamano
Convert most uses of OPT_BOOLEAN/OPTION_BOOLEAN that can use OPT_BOOL/OPTION_BOOLEAN which have much saner semantics, and turn remaining ones into OPT_SET_INT, OPT_COUNTUP, etc. as necessary. * sb/parseopt-boolean-removal: revert: use the OPT_CMDMODE for parsing, reducing code checkout-index: fix negations of even numbers of -n config parsing options: allow one flag multiple times hash-object: replace stdin parsing OPT_BOOLEAN by OPT_COUNTUP branch, commit, name-rev: ease up boolean conditions checkout: remove superfluous local variable log, format-patch: parsing uses OPT__QUIET Replace deprecated OPT_BOOLEAN by OPT_BOOL Remove deprecated OPTION_BOOLEAN for parsing arguments
2013-08-30Merge branch 'rj/doc-rev-parse'Junio C Hamano
* rj/doc-rev-parse: rev-parse(1): logically group options rev-parse: remove restrictions on some options
2013-08-05Replace deprecated OPT_BOOLEAN by OPT_BOOLStefan Beller
This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN, 2011-09-27). All occurrences of the respective variables have been reviewed and none of them relied on the counting up mechanism, but all of them were using the variable as a true boolean. This patch does not change semantics of any command intentionally. Signed-off-by: Stefan Beller <> Signed-off-by: Junio C Hamano <>
2013-07-22rev-parse: remove restrictions on some optionsJohn Keeping
The "--local-env-vars" and "--resolve-git-dir" arguments to git-rev-parse are currently only handled if they appear first on the command line (in the case of "--local-env-vars", only if it is the only argument). While it may not make sense to use these options when any others are specified, there is no reason for this restriction and it might confuse users if these arguments appear to be ignored. There is no need for any documentation change here as the restrictions on these options are not documented. Signed-off-by: John Keeping <> Signed-off-by: Junio C Hamano <>
2013-06-17rev-parse: add --prefix optionJohn Keeping
This makes 'git rev-parse' behave as if it were invoked from the specified subdirectory of a repository, with the difference that any file paths which it prints are prefixed with the full path from the top of the working tree. This is useful for shell scripts where we may want to cd to the top of the working tree but need to handle relative paths given by the user on the command line. Signed-off-by: John Keeping <> Signed-off-by: Junio C Hamano <>
2012-09-07Merge branch 'jc/dotdot-is-parent-directory'Junio C Hamano
"git log .." errored out saying it is both rev range and a path when there is no disambiguating "--" is on the command line. Update the command line parser to interpret ".." as a path in such a case. * jc/dotdot-is-parent-directory: specifying ranges: we did not mean to make ".." an empty set
2012-08-23specifying ranges: we did not mean to make ".." an empty setJunio C Hamano
Either end of revision range operator can be omitted to default to HEAD, as in "origin.." (what did I do since I forked) or "..origin" (what did they do since I forked). But the current parser interprets ".." as an empty range "HEAD..HEAD", and worse yet, because ".." does exist on the filesystem, we get this annoying output: $ cd Documentation/howto $ git log .. ;# give me recent commits that touch Documentation/ area. fatal: ambiguous argument '..': both revision and filename Use '--' to separate filenames from revisions Surely we could say "git log ../" or even "git log -- .." to disambiguate, but we shouldn't have to. Helped-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2012-08-20i18n: rev-parse: mark parseopt strings for translationNguyễn Thái Ngọc Duy
Signed-off-by: Nguyễn Thái Ngọc Duy <> Signed-off-by: Junio C Hamano <>
2012-07-22Merge branch 'jc/sha1-name-more'Junio C Hamano
Teaches the object name parser things like a "git describe" output is always a commit object, "A" in "git log A" must be a committish, and "A" and "B" in "git log A...B" both must be committish, etc., to prolong the lifetime of abbreviated object names. * jc/sha1-name-more: (27 commits) t1512: match the "other" object names t1512: ignore whitespaces in wc -l output rev-parse --disambiguate=<prefix> rev-parse: A and B in "rev-parse A..B" refer to committish reset: the command takes committish commit-tree: the command wants a tree and commits apply: --build-fake-ancestor expects blobs sha1_name.c: add support for disambiguating other types revision.c: the "log" family, except for "show", takes committish revision.c: allow handle_revision_arg() to take other flags sha1_name.c: introduce get_sha1_committish() sha1_name.c: teach lookup context to get_sha1_with_context() sha1_name.c: many short names can only be committish sha1_name.c: get_sha1_1() takes lookup flags sha1_name.c: get_describe_name() by definition groks only commits sha1_name.c: teach get_short_sha1() a commit-only option sha1_name.c: allow get_short_sha1() to take other flags get_sha1(): fix error status regression sha1_name.c: restructure disambiguation of short names sha1_name.c: correct misnamed "canonical" and "res" ...