summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2017-04-16Merge branch 'jk/snprintf-cleanups'Libravatar Junio C Hamano11-96/+99
Code clean-up. * jk/snprintf-cleanups: daemon: use an argv_array to exec children gc: replace local buffer with git_path transport-helper: replace checked snprintf with xsnprintf convert unchecked snprintf into xsnprintf combine-diff: replace malloc/snprintf with xstrfmt replace unchecked snprintf calls with heap buffers receive-pack: print --pack-header directly into argv array name-rev: replace static buffer with strbuf create_branch: use xstrfmt for reflog message create_branch: move msg setup closer to point of use avoid using mksnpath for refs avoid using fixed PATH_MAX buffers for refs fetch: use heap buffer to format reflog tag: use strbuf to format tag header diff: avoid fixed-size buffer for patch-ids odb_mkstemp: use git_path_buf odb_mkstemp: write filename into strbuf do not check odb_mkstemp return value for errors
2017-04-11Merge branch 'cc/untracked'Libravatar Junio C Hamano1-1/+5
Code cleanup. * cc/untracked: update-index: fix xgetcwd() related memory leak
2017-04-11Merge branch 'ah/log-decorate-default-to-auto'Libravatar Junio C Hamano1-1/+8
The default behaviour of "git log" in an interactive session has been changed to enable "--decorate". * ah/log-decorate-default-to-auto: log: if --decorate is not given, default to --decorate=auto
2017-04-11Merge branch 'ab/ref-filter-no-contains'Libravatar Junio C Hamano3-11/+26
"git tag/branch/for-each-ref" family of commands long allowed to filter the refs by "--contains X" (show only the refs that are descendants of X), "--merged X" (show only the refs that are ancestors of X), "--no-merged X" (show only the refs that are not ancestors of X). One curious omission, "--no-contains X" (show only the refs that are not descendants of X) has been added to them. * ab/ref-filter-no-contains: tag: add tests for --with and --without ref-filter: reflow recently changed branch/tag/for-each-ref docs ref-filter: add --no-contains option to tag/branch/for-each-ref tag: change --point-at to default to HEAD tag: implicitly supply --list given another list-like option tag: change misleading --list <pattern> documentation parse-options: add OPT_NONEG to the "contains" option tag: add more incompatibles mode tests for-each-ref: partly change <object> to <commit> in help tag tests: fix a typo in a test description tag: remove a TODO item from the test suite ref-filter: add test for --contains on a non-commit ref-filter: make combining --merged & --no-merged an error tag doc: reword --[no-]merged to talk about commits, not tips tag doc: split up the --[no-]merged documentation tag doc: move the description of --[no-]merged earlier
2017-03-30gc: replace local buffer with git_pathLibravatar Jeff King1-7/+1
We probe the "17/" loose object directory for auto-gc, and use a local buffer to format the path. We can just use git_path() for this. It handles paths of any length (reducing our error handling). And because we feed the result straight to a system call, we can just use the static variant. Note that git_path also knows the string "objects/" is special, and will replace it with git_object_directory() when necessary. Another alternative would be to use sha1_file_name() for the pretend object "170000...", but that ends up being more hassle for no gain, as we have to truncate the final path component. Signed-off-by: Jeff King <peff@peff.net>
2017-03-30replace unchecked snprintf calls with heap buffersLibravatar Jeff King3-11/+12
We'd prefer to avoid unchecked snprintf calls because truncation can lead to unexpected results. These are all cases where truncation shouldn't ever happen, because the input to snprintf is fixed in size. That makes them candidates for xsnprintf(), but it's simpler still to just use the heap, and then nobody has to wonder if "100" is big enough. We'll use xstrfmt() where possible, and a strbuf when we need the resulting size or to reuse the same buffer in a loop. Signed-off-by: Jeff King <peff@peff.net>
2017-03-30receive-pack: print --pack-header directly into argv arrayLibravatar Jeff King1-7/+10
After receive-pack reads the pack header from the client, it feeds the already-read part to index-pack and unpack-objects via their --pack-header command-line options. To do so, we format it into a fixed buffer, then duplicate it into the child's argv_array. Our buffer is long enough to handle any possible input, so this isn't wrong. But it's more complicated than it needs to be; we can just argv_array_pushf() the final value and avoid the intermediate copy. This drops the magic number and is more efficient, too. Note that we need to push to the argv_array in order, which means we can't do the push until we are in the "unpack-objects versus index-pack" conditional. Rather than duplicate the slightly complicated format specifier, I pushed it into a helper function. Signed-off-by: Jeff King <peff@peff.net>
2017-03-30name-rev: replace static buffer with strbufLibravatar Jeff King1-9/+12
When name-rev needs to format an actual name, we do so into a fixed-size buffer. That includes the actual ref tip, as well as any traversal information. Since refs can exceed 1024 bytes, this means you can get a bogus result. E.g., doing: git tag $(perl -e 'print join("/", 1..1024)') git describe --contains HEAD^ results in ".../282/283", when it should be ".../1023/1024~1". We can solve this by using a heap buffer. We'll use a strbuf, which lets us write into the same buffer from our loop without having to reallocate. Signed-off-by: Jeff King <peff@peff.net>
2017-03-30avoid using fixed PATH_MAX buffers for refsLibravatar Jeff King4-39/+41
Many functions which handle refs use a PATH_MAX-sized buffer to do so. This is mostly reasonable as we have to write loose refs into the filesystem, and at least on Linux the 4K PATH_MAX is big enough that nobody would care. But: 1. The static PATH_MAX is not always the filesystem limit. 2. On other platforms, PATH_MAX may be much smaller. 3. As we move to alternate ref storage, we won't be bound by filesystem limits. Let's convert these to heap buffers so we don't have to worry about truncation or size limits. We may want to eventually constrain ref lengths for sanity and to prevent malicious names, but we should do so consistently across all platforms, and in a central place (like the ref code). Signed-off-by: Jeff King <peff@peff.net>
2017-03-30fetch: use heap buffer to format reflogLibravatar Jeff King1-2/+4
Part of the reflog content comes from the environment, which can be much larger than our fixed buffer. Let's use a heap buffer so we avoid truncating it. Signed-off-by: Jeff King <peff@peff.net>
2017-03-30tag: use strbuf to format tag headerLibravatar Jeff King1-15/+12
We format the tag header into a fixed 1024-byte buffer. But since the tag-name and tagger ident can be arbitrarily large, we may unceremoniously die with "tag header too big". Let's just use a strbuf instead. Note that it looks at first glance like we can just format this directly into the "buf" strbuf where it will ultimately go. But that buffer may already contain the tag message, and we have no easy way to prepend formatted data to a strbuf (we can only splice in an already-generated buffer). This isn't a performance-critical path, so going through an extra buffer isn't a big deal. Signed-off-by: Jeff King <peff@peff.net>
2017-03-30Merge branch 'bc/push-cert-receive-fix'Libravatar Junio C Hamano1-1/+1
"git receive-pack" could have been forced to die by attempting allocate an unreasonably large amount of memory with a crafted push certificate; this has been fixed. * bc/push-cert-receive-fix: builtin/receive-pack: fix incorrect pointer arithmetic
2017-03-30Merge branch 'mg/describe-debug-l10n'Libravatar Junio C Hamano1-3/+12
Some debugging output from "git describe" were marked for l10n, but some weren't. Mark missing ones for l10n. * mg/describe-debug-l10n: l10n: de: translate describe debug terms describe: localize debug output fully
2017-03-30Merge branch 'bw/recurse-submodules-relative-fix'Libravatar Junio C Hamano2-36/+46
A few commands that recently learned the "--recurse-submodule" option misbehaved when started from a subdirectory of the superproject. * bw/recurse-submodules-relative-fix: ls-files: fix bug when recursing with relative pathspec ls-files: fix typo in variable name grep: fix bug when recursing with relative pathspec setup: allow for prefix to be passed to git commands grep: fix help text typo
2017-03-30Merge branch 'bw/submodule-is-active'Libravatar Junio C Hamano2-19/+99
"what URL do we want to update this submodule?" and "are we interested in this submodule?" are split into two distinct concepts, and then the way used to express the latter got extended, paving a way to make it easier to manage a project with many submodules and make it possible to later extend use of multiple worktrees for a project with submodules. * bw/submodule-is-active: submodule add: respect submodule.active and submodule.<name>.active submodule--helper init: set submodule.<name>.active clone: teach --recurse-submodules to optionally take a pathspec submodule init: initialize active submodules submodule: decouple url and submodule interest submodule--helper clone: check for configured submodules using helper submodule sync: use submodule--helper is-active submodule sync: skip work for inactive submodules submodule status: use submodule--helper is-active submodule--helper: add is-active subcommand
2017-03-30Merge branch 'jc/merge-drop-old-syntax'Libravatar Junio C Hamano1-50/+9
Stop supporting "git merge <message> HEAD <commit>" syntax that has been deprecated since October 2007, and issues a deprecation warning message since v2.5.0. * jc/merge-drop-old-syntax: merge: drop 'git merge <message> HEAD <commit>' syntax
2017-03-30update-index: fix xgetcwd() related memory leakLibravatar Christian Couder1-1/+5
As xgetcwd() returns an allocated buffer, we should free this buffer when we don't need it any more. This was found by Coverity. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-28odb_mkstemp: write filename into strbufLibravatar Jeff King1-3/+3
The odb_mkstemp() function expects the caller to provide a fixed buffer to write the resulting tempfile name into. But it creates the template using snprintf without checking the return value. This means we could silently truncate the filename. In practice, it's unlikely that the truncation would end in the template-pattern that mkstemp needs to open the file. So we'd probably end up failing either way, unless the path was specially crafted. The simplest fix would be to notice the truncation and die. However, we can observe that most callers immediately xstrdup() the result anyway. So instead, let's switch to using a strbuf, which is easier for them (and isn't a big deal for the other 2 callers, who can just strbuf_release when they're done with it). Note that many of the callers used static buffers, but this was purely to avoid putting a large buffer on the stack. We never passed the static buffers out of the function, so there's no complicated memory handling we need to change. Signed-off-by: Jeff King <peff@peff.net>
2017-03-28do not check odb_mkstemp return value for errorsLibravatar Jeff King1-3/+4
The odb_mkstemp function does not return an error; it dies on failure instead. But many of its callers compare the resulting descriptor against -1 and die themselves. Mostly this is just pointless, but it does raise a question when looking at the callers: if they show the results of the "template" buffer after a failure, what's in it? The answer is: it doesn't matter, because it cannot happen. So let's make that clear by removing the bogus error checks. In bitmap_writer_finish(), we can drop the error-handling code entirely. In the other two cases, it's shared with the open() in another code path; we can just move the error-check next to that open() call. And while we're at it, let's flesh out the function's docstring a bit to make the error behavior clear. Signed-off-by: Jeff King <peff@peff.net>
2017-03-28Merge branch 'jk/fast-import-cleanup'Libravatar Junio C Hamano1-4/+8
Code clean-up. * jk/fast-import-cleanup: pack.h: define largest possible encoded object size encode_in_pack_object_header: respect output buffer length fast-import: use xsnprintf for formatting headers fast-import: use xsnprintf for writing sha1s
2017-03-28Merge branch 'sb/checkout-recurse-submodules'Libravatar Junio C Hamano4-21/+60
"git checkout" is taught the "--recurse-submodules" option. * sb/checkout-recurse-submodules: builtin/read-tree: add --recurse-submodules switch builtin/checkout: add --recurse-submodules switch entry.c: create submodules when interesting unpack-trees: check if we can perform the operation for submodules unpack-trees: pass old oid to verify_clean_submodule update submodules: add submodule_move_head submodule.c: get_super_prefix_or_empty update submodules: move up prepare_submodule_repo_env submodules: introduce check to see whether to touch a submodule update submodules: add a config option to determine if submodules are updated update submodules: add submodule config parsing make is_submodule_populated gently lib-submodule-update.sh: define tests for recursing into submodules lib-submodule-update.sh: replace sha1 by hash lib-submodule-update: teach test_submodule_content the -C <dir> flag lib-submodule-update.sh: do not use ./. as submodule remote lib-submodule-update.sh: reorder create_lib_submodule_repo submodule--helper.c: remove duplicate code connect_work_tree_and_git_dir: safely create leading directories
2017-03-28Merge branch 'bw/grep-recurse-submodules'Libravatar Junio C Hamano1-12/+9
Build fix for NO_PTHREADS build. * bw/grep-recurse-submodules: grep: fix builds with with no thread support grep: set default output method
2017-03-28builtin/receive-pack: fix incorrect pointer arithmeticLibravatar brian m. carlson1-1/+1
If we had already processed the last newline in a push certificate, we would end up subtracting NULL from the end-of-certificate pointer when computing the length of the line. This would have resulted in an absurdly large length, and possibly a buffer overflow. Instead, subtract the beginning-of-certificate pointer from the end-of-certificate pointer, which is what's expected. Note that this situation should never occur, since not only do we require the certificate to be newline terminated, but the signature will only be read from the beginning of a line. Nevertheless, it seems prudent to correct it. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-27describe: localize debug output fullyLibravatar Michael J Gruber1-3/+12
git describe --debug localizes all debug messages but not the terms head, lightweight, annotated that it outputs for the candidates. Localize them, too. Signed-off-by: Michael J Gruber <git@grubix.eu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-27Merge branch 'sb/describe-broken'Libravatar Junio C Hamano1-9/+38
"git describe --dirty" dies when it cannot be determined if the state in the working tree matches that of HEAD (e.g. broken repository or broken submodule). The command learned a new option "git describe --broken" to give "$name-broken" (where $name is the description of HEAD) in such a case. * sb/describe-broken: builtin/describe: introduce --broken flag
2017-03-27Merge branch 'sb/push-options-via-transport'Libravatar Junio C Hamano1-0/+5
Recently we started passing the "--push-options" through the external remote helper interface; now the "smart HTTP" remote helper understands what to do with the passed information. * sb/push-options-via-transport: remote-curl: allow push options send-pack: send push options correctly in stateless-rpc case
2017-03-27Merge branch 'jk/prefix-filename'Libravatar Junio C Hamano8-38/+27
Code clean-up with minor bugfixes. * jk/prefix-filename: bundle: use prefix_filename with bundle path prefix_filename: simplify windows #ifdef prefix_filename: return newly allocated string prefix_filename: drop length parameter prefix_filename: move docstring to header file hash-object: fix buffer reuse with --path in a subdirectory
2017-03-24Merge branch 'rs/update-hook-optim'Libravatar Junio C Hamano1-8/+5
Code clean-up. * rs/update-hook-optim: receive-pack: simplify run_update_post_hook()
2017-03-24Merge branch 'rs/shortlog-cleanup'Libravatar Junio C Hamano1-1/+0
Code clean-up. * rs/shortlog-cleanup: shortlog: don't set after_subject to an empty string
2017-03-24pack.h: define largest possible encoded object sizeLibravatar Jeff King1-2/+4
Several callers use fixed buffers for storing the pack object header, and they've picked 10 as a magic number. This is reasonable, since it handles objects up to 2^67. But let's give them a constant so it's clear that the number isn't pulled out of thin air. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24encode_in_pack_object_header: respect output buffer lengthLibravatar Jeff King1-2/+4
The encode_in_pack_object_header() writes a variable-length header to an output buffer, but it doesn't actually know long the buffer is. At first glance, this looks like it might be possible to overflow. In practice, this is probably impossible. The smallest buffer we use is 10 bytes, which would hold the header for an object up to 2^67 bytes. Obviously we're not likely to see such an object, but we might worry that an object could lie about its size (causing us to overflow before we realize it does not actually have that many bytes). But the argument is passed as a uintmax_t. Even on systems that have __int128 available, uintmax_t is typically restricted to 64-bit by the ABI. So it's unlikely that a system exists where this could be exploited. Still, it's easy enough to use a normal out/len pair and make sure we don't write too far. That protects the hypothetical 128-bit system, makes it harder for callers to accidentally specify a too-small buffer, and makes the resulting code easier to audit. Note that the one caller in fast-import tried to catch such a case, but did so _after_ the call (at which point we'd have already overflowed!). This check can now go away. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24ref-filter: add --no-contains option to tag/branch/for-each-refLibravatar Ævar Arnfjörð Bjarmason3-4/+12
Change the tag, branch & for-each-ref commands to have a --no-contains option in addition to their longstanding --contains options. This allows for finding the last-good rollout tag given a known-bad <commit>. Given a hypothetically bad commit cf5c7253e0, the git version to revert to can be found with this hacky two-liner: (git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') | sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10 With this new --no-contains option the same can be achieved with: git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10 As the filtering machinery is shared between the tag, branch & for-each-ref commands, implement this for those commands too. A practical use for this with "branch" is e.g. finding branches which were branched off between v2.8.0 and v2.10.0: git branch --contains v2.8.0 --no-contains v2.10.0 The "describe" command also has a --contains option, but its semantics are unrelated to what tag/branch/for-each-ref use --contains for. A --no-contains option for "describe" wouldn't make any sense, other than being exactly equivalent to not supplying --contains at all, which would be confusing at best. Add a --without option to "tag" as an alias for --no-contains, for consistency with --with and --contains. The --with option is undocumented, and possibly the only user of it is Junio (<xmqqefy71iej.fsf@gitster.mtv.corp.google.com>). But it's trivial to support, so let's do that. The additions to the the test suite are inverse copies of the corresponding --contains tests. With this change --no-contains for tag, branch & for-each-ref is just as well tested as the existing --contains option. In addition to those tests, add a test for "tag" which asserts that --no-contains won't find tree/blob tags, which is slightly unintuitive, but consistent with how --contains works & is documented. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24tag: change --point-at to default to HEADLibravatar Ævar Arnfjörð Bjarmason1-1/+2
Change the --points-at option to default to HEAD for consistency with its siblings --contains, --merged etc. which default to HEAD. Previously we'd get: $ git tag --points-at 2>&1 | head -n 1 error: option `points-at' requires a value This changes behavior added in commit ae7706b9ac (tag: add --points-at list option, 2012-02-08). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24tag: implicitly supply --list given another list-like optionLibravatar Ævar Arnfjörð Bjarmason1-6/+12
Change the "tag" command to implicitly turn on its --list mode when provided with a list-like option such as --contains, --points-at etc. This is for consistency with how "branch" works. When "branch" is given a list-like option, such as --contains, it implicitly provides --list. Before this change "tag" would error out on those sorts of invocations. I.e. while both of these worked for "branch": git branch --contains v2.8.0 <pattern> git branch --list --contains v2.8.0 <pattern> Only the latter form worked for "tag": git tag --contains v2.8.0 '*rc*' git tag --list --contains v2.8.0 '*rc*' Now "tag", like "branch", will implicitly supply --list when a list-like option is provided, and no other conflicting non-list options (such as -d) are present on the command-line. Spelunking through the history via: git log --reverse -p -G'only allowed with' -- '*builtin*tag*c' Reveals that there was no good reason for not allowing this in the first place. The --contains option added in 32c35cfb1e ("git-tag: Add --contains option", 2009-01-26) made this an error. All the other subsequent list-like options that were added copied its pattern of making this usage an error. The only tests that break as a result of this change are tests that were explicitly checking that this "branch-like" usage wasn't permitted. Change those failing tests to check that this invocation mode is permitted, add extra tests for the list-like options we weren't testing, and tests to ensure that e.g. we don't toggle the list mode in the presence of other conflicting non-list options. With this change errors messages such as "--contains option is only allowed with -l" don't make sense anymore, since options like --contain turn on -l. Instead we error out when list-like options such as --contain are used in conjunction with conflicting options such as -d or -v. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-24log: if --decorate is not given, default to --decorate=autoLibravatar Alex Henrie1-1/+8
Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-23for-each-ref: partly change <object> to <commit> in helpLibravatar Ævar Arnfjörð Bjarmason1-2/+2
Change mentions of <object> to <commit> in the help output of for-each-ref as appropriate. Both --[no-]merged and --contains only take commits, but --points-at can take any object, such as a tag pointing to a tree or blob. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-22remote-curl: allow push optionsLibravatar Brandon Williams1-0/+5
Teach remote-curl to understand push options and to be able to convey them across HTTP. Signed-off-by: Brandon Williams <bmwill@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-22builtin/describe: introduce --broken flagLibravatar Stefan Beller1-9/+38
git-describe tells you the version number you're at, or errors out, e.g. when you run it outside of a repository, which may happen when downloading a tar ball instead of using git to obtain the source code. To keep this property of only erroring out, when not in a repository, severe (submodule) errors must be downgraded to reporting them gently instead of having git-describe error out completely. To achieve that a flag '--broken' is introduced, which is in the same vein as '--dirty' but uses an actual child process to check for dirtiness. When that child dies unexpectedly, we'll append '-broken' instead of '-dirty'. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-21Merge branch 'jk/pack-name-cleanups'Libravatar Junio C Hamano1-16/+15
Code clean-up. * jk/pack-name-cleanups: index-pack: make pointer-alias fallbacks safer replace snprintf with odb_pack_name() odb_pack_keep(): stop generating keepfile name sha1_file.c: make pack-name helper globally accessible move odb_* declarations out of git-compat-util.h
2017-03-21Merge branch 'jk/rev-parse-cleanup'Libravatar Junio C Hamano1-52/+57
Code clean-up. * jk/rev-parse-cleanup: rev-parse: simplify parsing of ref options rev-parse: add helper for parsing "--foo/--foo=" rev-parse: use skip_prefix when parsing options
2017-03-21Merge branch 'jk/show-branch-lift-name-len-limit' into maintLibravatar Junio C Hamano1-29/+13
"git show-branch" expected there were only very short branch names in the repository and used a fixed-length buffer to hold them without checking for overflow. * jk/show-branch-lift-name-len-limit: show-branch: use skip_prefix to drop magic numbers show-branch: store resolved head in heap buffer show-branch: drop head_len variable
2017-03-21Merge branch 'rl/remote-allow-missing-branch-name-merge' into maintLibravatar Junio C Hamano1-1/+3
"git remote rm X", when a branch has remote X configured as the value of its branch.*.remote, tried to remove branch.*.remote and branch.*.merge and failed if either is unset. * rl/remote-allow-missing-branch-name-merge: remote: ignore failure to remove missing branch.<name>.merge
2017-03-21Merge branch 'dt/gc-ignore-old-gc-logs' into maintLibravatar Junio C Hamano1-7/+50
A "gc.log" file left by a backgrounded "gc --auto" disables further automatic gc; it has been taught to run at least once a day (by default) by ignoring a stale "gc.log" file that is too old. * dt/gc-ignore-old-gc-logs: gc: ignore old gc.log files
2017-03-21bundle: use prefix_filename with bundle pathLibravatar Jeff King1-7/+1
We may take the path to a bundle file as an argument, and need to adjust the filename based on the prefix we discovered while setting up the git directory. We do so manually into a fixed-size buffer, but using prefix_filename() is the normal way. Besides being more concise, there are two subtle improvements: 1. The original inserted a "/" between the two paths, even though the "prefix" argument always has the "/" appended. That means that: cd subdir && git bundle verify ../foo.bundle was looking at (and reporting) subdir//../foo.bundle. Harmless, but ugly. Using prefix_filename() gets this right. 2. The original checked for an absolute path by looking for a leading '/'. It should have been using is_absolute_path(), which also covers more cases on Windows (backslashes and dos drive prefixes). But it's easier still to just pass the name to prefix_filename(), which handles this case automatically. Note that we'll just leak the resulting buffer in the name of simplicity, since it needs to last through the duration of the program anyway. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-21prefix_filename: return newly allocated stringLibravatar Jeff King7-18/+21
The prefix_filename() function returns a pointer to static storage, which makes it easy to use dangerously. We already fixed one buggy caller in hash-object recently, and the calls in apply.c are suspicious (I didn't dig in enough to confirm that there is a bug, but we call the function once in apply_all_patches() and then again indirectly from parse_chunk()). Let's make it harder to get wrong by allocating the return value. For simplicity, we'll do this even when the prefix is empty (and we could just return the original file pointer). That will cause us to allocate sometimes when we wouldn't otherwise need to, but this function isn't called in performance critical code-paths (and it already _might_ allocate on any given call, so a caller that cares about performance is questionable anyway). The downside is that the callers need to remember to free() the result to avoid leaking. Most of them already used xstrdup() on the result, so we know they are OK. The remainder have been converted to use free() as appropriate. I considered retaining a prefix_filename_unsafe() for cases where we know the static lifetime is OK (and handling the cleanup is awkward). This is only a handful of cases, though, and it's not worth the mental energy in worrying about whether the "unsafe" variant is OK to use in any situation. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-21prefix_filename: drop length parameterLibravatar Jeff King7-20/+9
This function takes the prefix as a ptr/len pair, but in every caller the length is exactly strlen(ptr). Let's simplify the interface and just take the string. This saves callers specifying it (and in some cases handling a NULL prefix). In a handful of cases we had the length already without calling strlen, so this is technically slower. But it's not likely to matter (after all, if the prefix is non-empty we'll allocate and copy it into a buffer anyway). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-21hash-object: fix buffer reuse with --path in a subdirectoryLibravatar Jeff King1-2/+5
The hash-object command uses prefix_filename() without duplicating its return value. Since that function returns a static buffer, the value is overwritten by subsequent calls. This can cause incorrect results when we use --path along with hashing a file by its relative path, both of which need to call prefix_filename(). We overwrite the filename computed for --path, effectively ignoring it. We can fix this by calling xstrdup on the return value. Note that we don't bother freeing the "vpath" instance, as it remains valid until the program exit. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-20Merge branch 'js/difftool-builtin'Libravatar Junio C Hamano1-5/+46
"git difftool --dir-diff" used to die a controlled death giving a "fatal" message when encountering a locally modified symbolic link, but it started segfaulting since v2.12. This has been fixed. * js/difftool-builtin: difftool: handle modified symlinks in dir-diff mode t7800: cleanup cruft left behind by tests t7800: remove whitespace before redirect
2017-03-18shortlog: don't set after_subject to an empty stringLibravatar René Scharfe1-1/+0
The string after_subject is added to a strbuf by pp_title_line() if it's not NULL. Adding an empty string has the same effect as not adding anything, but the latter is easier, so don't bother changing the context member from NULL to "". Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-18receive-pack: simplify run_update_post_hook()Libravatar René Scharfe1-8/+5
Instead of counting the arguments to see if there are any and then building the full command use a single loop and add the hook command just before the first argument. This reduces duplication and overall code size. Signed-off-by: Rene Scharfe <l.s.r@web.de> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>