summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-02-22fetch-pack: simplify add_sought_entryLibravatar Jeff King1-18/+9
We have two variants of this function, one that takes a string and one that takes a ptr/len combo. But we only call the latter with the length of a NUL-terminated string, so our first simplification is to drop it in favor of the string variant. Since we know we have a string, we can also replace the manual memory computation with a call to alloc_ref(). Furthermore, we can rely on get_oid_hex() to complain if it hits the end of the string. That means we can simplify the check for "<sha1> <ref>" versus just "<ref>". Rather than manage the ptr/len pair, we can just bump the start of our string forward. The original code over-allocated based on the original "namelen" (which wasn't _wrong_, but was simply wasteful and confusing). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22fast-import: simplify allocation in start_packfileLibravatar Jeff King1-4/+1
This function allocate a packed_git flex-array, and adds a mysterious 2 bytes to the length of the pack_name field. One is for the trailing NUL, but the other has no purpose. This is probably cargo-culted from add_packed_git, which gets the ".idx" path and needed to allocate enough space to hold the matching ".pack" (though since 48bcc1c, we calculate the size there differently). This site, however, is using the raw path of a tempfile, and does not need the extra byte. We can just replace the allocation with FLEX_ALLOC_STR, which handles the allocation and the NUL for us. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22write_untracked_extension: use FLEX_ALLOC helperLibravatar Jeff King1-5/+4
We perform unchecked additions when computing the size of a "struct ondisk_untracked_cache". This is unlikely to have an integer overflow in practice, but we'd like to avoid this dangerous pattern to make further audits easier. Note that there's one subtlety here, though. We protect ourselves against a NULL exclude_per_dir entry in our source, and avoid calling strlen() on it, keeping "len" at 0. But later, we unconditionally memcpy "len + 1" bytes to get the trailing NUL byte. If we did have a NULL exclude_per_dir, we would read from bogus memory. As it turns out, though, we always create this field pointing to a string literal, so there's no bug. We can just get rid of the pointless extra conditional. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22prepare_{git,shell}_cmd: use argv_arrayLibravatar Jeff King3-53/+39
These functions transform an existing argv into one suitable for exec-ing or spawning via git or a shell. We can use an argv_array in each to avoid dealing with manual counting and allocation. This also makes the memory allocation more clear and fixes some leaks. In prepare_shell_cmd, we would sometimes allocate a new string with "$@" in it and sometimes not, meaning the caller could not correctly free it. On the non-Windows side, we are in a child process which will exec() or exit() immediately, so the leak isn't a big deal. On Windows, though, we use spawn() from the parent process, and leak a string for each shell command we run. On top of that, the Windows code did not free the allocated argv array at all (but does for the prepare_git_cmd case!). By switching both of these functions to write into an argv_array, we can consistently free the result as appropriate. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22use st_add and st_mult for allocation size computationLibravatar Jeff King25-53/+56
If our size computation overflows size_t, we may allocate a much smaller buffer than we expected and overflow it. It's probably impossible to trigger an overflow in most of these sites in practice, but it is easy enough convert their additions and multiplications into overflow-checking variants. This may be fixing real bugs, and it makes auditing the code easier. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22convert trivial cases to FLEX_ARRAY macrosLibravatar Jeff King17-82/+35
Using FLEX_ARRAY macros reduces the amount of manual computation size we have to do. It also ensures we don't overflow size_t, and it makes sure we write the same number of bytes that we allocated. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22use xmallocz to avoid size arithmeticLibravatar Jeff King15-25/+17
We frequently allocate strings as xmalloc(len + 1), where the extra 1 is for the NUL terminator. This can be done more simply with xmallocz, which also checks for integer overflow. There's no case where switching xmalloc(n+1) to xmallocz(n) is wrong; the result is the same length, and malloc made no guarantees about what was in the buffer anyway. But in some cases, we can stop manually placing NUL at the end of the allocated buffer. But that's only safe if it's clear that the contents will always fill the buffer. In each case where this patch does so, I manually examined the control flow, and I tried to err on the side of caution. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22convert trivial cases to ALLOC_ARRAYLibravatar Jeff King34-64/+75
Each of these cases can be converted to use ALLOC_ARRAY or REALLOC_ARRAY, which has two advantages: 1. It automatically checks the array-size multiplication for overflow. 2. It always uses sizeof(*array) for the element-size, so that it can never go out of sync with the declared type of the array. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22convert manual allocations to argv_arrayLibravatar Jeff King7-76/+43
There are many manual argv allocations that predate the argv_array API. Switching to that API brings a few advantages: 1. We no longer have to manually compute the correct final array size (so it's one less thing we can screw up). 2. In many cases we had to make a separate pass to count, then allocate, then fill in the array. Now we can do it in one pass, making the code shorter and easier to follow. 3. argv_array handles memory ownership for us, making it more obvious when things should be free()d and and when not. Most of these cases are pretty straightforward. In some, we switch from "run_command_v" to "run_command" which lets us directly use the argv_array embedded in "struct child_process". Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22argv-array: add detach functionLibravatar Jeff King3-0/+19
The usual pattern for an argv array is to initialize it, push in some strings, and then clear it when done. Very occasionally, though, we must do other exotic things with the memory, like freeing the list but keeping the strings. Let's provide a detach function so that callers can make use of our API to build up the array, and then take ownership of it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22add helpers for allocating flex-array structsLibravatar Jeff King1-0/+62
Allocating a struct with a flex array is pretty simple in practice: you over-allocate the struct, then copy some data into the over-allocation. But it can be a slight pain to make sure you're allocating and copying the right amounts. This patch adds a few helpers to turn simple cases of flex-array struct allocation into a one-liner that properly checks for overflow. See the embedded documentation for details. Ideally we could provide a more flexible version that could handle multiple strings, like: FLEX_ALLOC_FMT(ref, name, "%s%s", prefix, name); But we have to implement this as a macro (because of the offset calculation of the flex member), which means we would need all compilers to support variadic macros. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22harden REALLOC_ARRAY and xcalloc against size_t overflowLibravatar Jeff King2-1/+5
REALLOC_ARRAY inherently involves a multiplication which can overflow size_t, resulting in a much smaller buffer than we think we've allocated. We can easily harden it by using st_mult() to check for overflow. Likewise, we can add ALLOC_ARRAY to do the same thing for xmalloc calls. xcalloc() should already be fine, because it takes the two factors separately, assuming the system calloc actually checks for overflow. However, before we even hit the system calloc(), we do our memory_limit_check, which involves a multiplication. Let's check for overflow ourselves so that this limit cannot be bypassed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-19tree-diff: catch integer overflow in combine_diff_path allocationLibravatar Jeff King2-4/+4
A combine_diff_path struct has two "flex" members allocated alongside the struct: a string to hold the pathname, and an array of parent pointers. We use an "int" to compute this, meaning we may easily overflow it if the pathname is extremely long. We can fix this by using size_t, and checking for overflow with the st_add helper. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-19add helpers for detecting size_t overflowLibravatar Jeff King1-0/+34
Performing computations on size_t variables that we feed to xmalloc and friends can be dangerous, as an integer overflow can cause us to allocate a much smaller chunk than we realized. We already have unsigned_add_overflows(), but let's add unsigned_mult_overflows() to that. Furthermore, rather than have each site manually check and die on overflow, we can provide some helpers that will: - promote the arguments to size_t, so that we know we are doing our computation in the same size of integer that will ultimately be fed to xmalloc - check and die on overflow - return the result so that computations can be done in the parameter list of xmalloc. These functions are a lot uglier to use than normal arithmetic operators (you have to do "st_add(foo, bar)" instead of "foo + bar"). To at least limit the damage, we also provide multi-valued versions. So rather than: st_add(st_add(a, b), st_add(c, d)); you can write: st_add4(a, b, c, d); This isn't nearly as elegant as a varargs function, but it's a lot harder to get it wrong. You don't have to remember to add a sentinel value at the end, and the compiler will complain if you get the number of arguments wrong. This patch adds only the numbered variants required to convert the current code base; we can easily add more later if needed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-19reflog_expire_cfg: NUL-terminate pattern fieldLibravatar Jeff King1-5/+3
You can tweak the reflog expiration for a particular subset of refs by configuring gc.foo.reflogexpire. We keep a linked list of reflog_expire_cfg structs, each of which holds the pattern and a "len" field for the length of the pattern. The pattern itself is _not_ NUL-terminated. However, we feed the pattern directly to wildmatch(), which expects a NUL-terminated string, meaning it may keep reading random junk after our struct. We can fix this by allocating an extra byte for the NUL (which is already zero because we use xcalloc). Let's also drop the misleading "len" field, which is no longer necessary. The existing use of "len" can be converted to use strncmp(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-05Git 2.7.1Libravatar Junio C Hamano4-3/+91
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-05Merge branch 'lv/add-doc-working-tree' into maintLibravatar Junio C Hamano1-1/+1
* lv/add-doc-working-tree: git-add doc: do not say working directory when you mean working tree
2016-02-05Merge branch 'ss/clone-depth-single-doc' into maintLibravatar Junio C Hamano2-9/+9
Documentation for "git fetch --depth" has been updated for clarity. * ss/clone-depth-single-doc: docs: clarify that --depth for git-fetch works with newly initialized repos docs: say "commits" in the --depth option wording for git-clone docs: clarify that passing --depth to git-clone implies --single-branch
2016-02-05Merge branch 'sg/t6050-failing-editor-test-fix' into maintLibravatar Junio C Hamano1-3/+7
* sg/t6050-failing-editor-test-fix: t6050-replace: make failing editor test more robust
2016-02-05Merge branch 'ew/for-each-ref-doc' into maintLibravatar Junio C Hamano1-2/+7
* ew/for-each-ref-doc: for-each-ref: document `creatordate` and `creator` fields
2016-02-05Merge branch 'ss/user-manual' into maintLibravatar Junio C Hamano2-10/+36
Drop a few old "todo" items by deciding that the change one of them suggests is not such a good idea, and doing the change the other one suggested to do. * ss/user-manual: user-manual: add addition gitweb information user-manual: add section documenting shallow clones glossary: define the term shallow clone user-manual: remove temporary branch entry from todo list
2016-02-05Merge branch 'jk/ref-cache-non-repository-optim' into maintLibravatar Junio C Hamano6-40/+80
The underlying machinery used by "ls-files -o" and other commands have been taught not to create empty submodule ref cache for a directory that is not a submodule. This removes a ton of wasted CPU cycles. * jk/ref-cache-non-repository-optim: resolve_gitlink_ref: ignore non-repository paths clean: make is_git_repository a public function
2016-02-05Merge branch 'js/dirname-basename' into maintLibravatar Junio C Hamano7-24/+225
dirname() emulation has been added, as Msys2 lacks it. * js/dirname-basename: mingw: avoid linking to the C library's isalpha() t0060: loosen overly strict expectations t0060: verify that basename() and dirname() work as expected compat/basename.c: provide a dirname() compatibility function compat/basename: make basename() conform to POSIX Refactor skipping DOS drive prefixes
2016-02-05Merge branch 'tb/complete-word-diff-regex' into maintLibravatar Junio C Hamano1-1/+1
* tb/complete-word-diff-regex: completion: complete "diff --word-diff-regex="
2016-02-05Merge branch 'pw/completion-stash' into maintLibravatar Junio C Hamano1-3/+14
* pw/completion-stash: completion: update completion arguments for stash
2016-02-05Merge branch 'pw/completion-show-branch' into maintLibravatar Junio C Hamano1-1/+1
* pw/completion-show-branch: completion: complete show-branch "--date-order"
2016-02-05Merge branch 'jk/completion-rebase' into maintLibravatar Junio C Hamano1-2/+6
* jk/completion-rebase: completion: add missing git-rebase options
2016-02-05Merge branch 'nd/diff-with-path-params' into maintLibravatar Junio C Hamano7-12/+25
A few options of "git diff" did not work well when the command was run from a subdirectory. * nd/diff-with-path-params: diff: make -O and --output work in subdirectory diff-no-index: do not take a redundant prefix argument
2016-02-05Merge branch 'dw/subtree-split-do-not-drop-merge' into maintLibravatar Junio C Hamano2-2/+70
The "split" subcommand of "git subtree" (in contrib/) incorrectly skipped merges when it shouldn't, which was corrected. * dw/subtree-split-do-not-drop-merge: contrib/subtree: fix "subtree split" skipped-merge bug
2016-02-05Merge branch 'ew/svn-1.9.0-auth' into maintLibravatar Junio C Hamano1-2/+6
* ew/svn-1.9.0-auth: git-svn: fix auth parameter handling on SVN 1.9.0+
2016-02-05Merge branch 'jk/list-tag-2.7-regression' into maintLibravatar Junio C Hamano7-56/+72
"git tag" started listing a tag "foo" as "tags/foo" when a branch named "foo" exists in the same repository; remove this unnecessary disambiguation, which is a regression introduced in v2.7.0. * jk/list-tag-2.7-regression: tag: do not show ambiguous tag names as "tags/foo" t6300: use test_atom for some un-modern tests
2016-02-05Merge branch 'jk/sanity' into maintLibravatar Junio C Hamano1-5/+13
The description for SANITY prerequisite the test suite uses has been clarified both in the comment and in the implementation. * jk/sanity: test-lib: clarify and tighten SANITY
2016-02-05Merge branch 'jk/filter-branch-no-index' into maintLibravatar Junio C Hamano2-1/+9
A recent optimization to filter-branch in v2.7.0 introduced a regression when --prune-empty filter is used, which has been corrected. * jk/filter-branch-no-index: filter-branch: resolve $commit^{tree} in no-index case
2016-02-05Merge branch 'js/close-packs-before-gc' into maintLibravatar Junio C Hamano5-0/+18
Many codepaths that run "gc --auto" before exiting kept packfiles mapped and left the file descriptors to them open, which was not friendly to systems that cannot remove files that are open. They now close the packs before doing so. * js/close-packs-before-gc: receive-pack: release pack files before garbage-collecting merge: release pack files before garbage-collecting am: release pack files before garbage-collecting fetch: release pack files before garbage-collecting
2016-02-05Merge branch 'jk/ok-to-fail-gc-auto-in-rebase' into maintLibravatar Junio C Hamano1-1/+1
"git rebase", unlike all other callers of "gc --auto", did not ignore the exit code from "gc --auto". * jk/ok-to-fail-gc-auto-in-rebase: rebase: ignore failures from "gc --auto"
2016-02-05Merge branch 'ho/gitweb-squelch-undef-warning' into maintLibravatar Junio C Hamano1-1/+1
Asking gitweb for a nonexistent commit left a warning in the server log. Somebody may want to follow this up with a new test, perhaps? IIRC, we do test that no Perl warnings are given to the server log, so this should have been caught if our test coverage were good. * ho/gitweb-squelch-undef-warning: gitweb: squelch "uninitialized value" warning
2016-02-05Merge branch 'js/fopen-harder' into maintLibravatar Junio C Hamano5-3/+17
Some codepaths used fopen(3) when opening a fixed path in $GIT_DIR (e.g. COMMIT_EDITMSG) that is meant to be left after the command is done. This however did not work well if the repository is set to be shared with core.sharedRepository and the umask of the previous user is tighter. They have been made to work better by calling unlink(2) and retrying after fopen(3) fails with EPERM. * js/fopen-harder: Handle more file writes correctly in shared repos commit: allow editing the commit message even in shared repos
2016-02-05Merge branch 'nd/exclusion-regression-fix' into maintLibravatar Junio C Hamano3-118/+6
The ignore mechanism saw a few regressions around untracked file listing and sparse checkout selection areas in 2.7.0; the change that is responsible for the regression has been reverted. * nd/exclusion-regression-fix: Revert "dir.c: don't exclude whole dir prematurely if neg pattern may match"
2016-02-05Merge branch 'dk/reflog-walk-with-non-commit' into maintLibravatar Junio C Hamano2-5/+24
"git reflog" incorrectly assumed that all objects that used to be at the tip of a ref must be commits, which caused it to segfault. * dk/reflog-walk-with-non-commit: reflog-walk: don't segfault on non-commit sha1's in the reflog
2016-02-05Merge branch 'dw/signoff-doc' into maintLibravatar Junio C Hamano5-1/+9
The documentation has been updated to hint the connection between the '--signoff' option and DCO. * dw/signoff-doc: Expand documentation describing --signoff
2016-02-05Merge branch 'jk/clang-pedantic' into maintLibravatar Junio C Hamano4-5/+6
A few unportable C construct have been spotted by clang compiler and have been fixed. * jk/clang-pedantic: bswap: add NO_UNALIGNED_LOADS define avoid shifting signed integers 31 bits
2016-02-05Merge branch 'ew/send-email-mutt-alias-fix' into maintLibravatar Junio C Hamano2-2/+22
"git send-email" was confused by escaped quotes stored in the alias files saved by "mutt", which has been corrected. * ew/send-email-mutt-alias-fix: git-send-email: do not double-escape quotes from mutt
2016-02-05Merge branch 'nd/dir-exclude-cleanup' into maintLibravatar Junio C Hamano1-3/+1
The "exclude_list" structure has the usual "alloc, nr" pair of fields to be used by ALLOC_GROW(), but clear_exclude_list() forgot to reset 'alloc' to 0 when it cleared 'nr' to discard the managed array. * nd/dir-exclude-cleanup: dir.c: clean the entire struct in clear_exclude_list()
2016-02-05Merge branch 'nd/stop-setenv-work-tree' into maintLibravatar Junio C Hamano2-3/+1
An earlier change in 2.5.x-era broke users' hooks and aliases by exporting GIT_WORK_TREE to point at the root of the working tree, interfering when they tried to use a different working tree without setting GIT_WORK_TREE environment themselves. * nd/stop-setenv-work-tree: Revert "setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR"
2016-01-26git-svn: fix auth parameter handling on SVN 1.9.0+Libravatar Eric Wong1-2/+6
For users with "store-passwords = no" set in the "[auth]" section of their ~/.subversion/config, SVN 1.9.0+ would fail with the following message when attempting to call svn_auth_set_parameter: Value is not a string (or undef) at Git/SVN/Ra.pm Ironically, this breakage was caused by r1553823 in subversion: "Make svn_auth_set_parameter() usable from Perl bindings." Since 2007 (602015e0e6ec), git-svn has used a workaround to make svn_auth_set_parameter usable internally. However this workaround breaks under SVN 1.9+, which deals properly with the type mapping and fails to recognize our workaround. For pre-1.9.0 SVN, we continue to use the existing workaround for the lack of proper type mapping in the bindings. Tested under subversion 1.6.17 and 1.9.3. I've also verified r1553823 was not backported to SVN 1.8.x: BRANCH=http://svn.apache.org/repos/asf/subversion/branches/1.8.x svn log -v $BRANCH/subversion/bindings/swig/core.i ref: https://bugs.debian.org/797705 Cc: 797705@bugs.debian.org Reported-by: Thierry Vignaud <thierry.vignaud@gmail.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Tested-by: Thierry Vignaud <thierry.vignaud@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26tag: do not show ambiguous tag names as "tags/foo"Libravatar Jeff King7-4/+62
Since b7cc53e9 (tag.c: use 'ref-filter' APIs, 2015-07-11), git-tag has started showing tags with ambiguous names (i.e., when both "heads/foo" and "tags/foo" exists) as "tags/foo" instead of just "foo". This is both: - pointless; the output of "git tag" includes only refs/tags, so we know that "foo" means the one in "refs/tags". and - ambiguous; in the original output, we know that the line "foo" means that "refs/tags/foo" exists. In the new output, it is unclear whether we mean "refs/tags/foo" or "refs/tags/tags/foo". The reason this happens is that commit b7cc53e9 switched git-tag to use ref-filter's "%(refname:short)" output formatting, which was adapted from for-each-ref. This more general code does not know that we care only about tags, and uses shorten_unambiguous_ref to get the short-name. We need to tell it that we care only about "refs/tags/", and it should shorten with respect to that value. In theory, the ref-filter code could figure this out by us passing FILTER_REFS_TAGS. But there are two complications there: 1. The handling of refname:short is deep in formatting code that does not even have our ref_filter struct, let alone the arguments to the filter_ref struct. 2. In git v2.7.0, we expose the formatting language to the user. If we follow this path, it will mean that "%(refname:short)" behaves differently for "tag" versus "for-each-ref" (including "for-each-ref refs/tags/"), which can lead to confusion. Instead, let's add a new modifier to the formatting language, "strip", to remove a specific set of prefix components. This fixes "git tag", and lets users invoke the same behavior from their own custom formats (for "tag" or "for-each-ref") while leaving ":short" with its same consistent meaning in all places. We introduce a test in t7004 for "git tag", which fails without this patch. We also add a similar test in t3203 for "git branch", which does not actually fail. But since it is likely that "branch" will eventually use the same formatting code, the test helps defend against future regressions. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-26completion: update completion arguments for stashLibravatar Paul Wagland1-3/+14
Add --all and --include-untracked to the git stash save completions. Add --quiet to the git stash drop completions. Update git stash branch so that the first argument expands out to the possible branch names, and the other arguments expand to the stash names. Signed-off-by: Paul Wagland <paul@kungfoocoder.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25completion: complete show-branch "--date-order"Libravatar Paul Wagland1-1/+1
Signed-off-by: Paul Wagland <paul@kungfoocoder.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25completion: add missing git-rebase optionsLibravatar John Keeping1-2/+6
This adds the --no-* variants where those are documented in git-rebase(1). Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-25mingw: avoid linking to the C library's isalpha()Libravatar Johannes Sixt2-6/+8
The implementation of mingw_skip_dos_drive_prefix() calls isalpha() via has_dos_drive_prefix(). Since the definition occurs long before isalpha() is defined in git-compat-util.h, my build environment reports: CC alloc.o In file included from git-compat-util.h:186, from cache.h:4, from alloc.c:12: compat/mingw.h: In function 'mingw_skip_dos_drive_prefix': compat/mingw.h:365: warning: implicit declaration of function 'isalpha' Dscho does not see a similar warning in his build and suspects that ctype.h is included somehow behind the scenes. This implies that his build links to the C library's isalpha() and does not use git's isalpha(). To fix both the warning in my build and the inconsistency in Dscho's build, move the function definition to mingw.c. Then it picks up git's isalpha() because git-compat-util.h is included at the top of the file. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>