aboutsummaryrefslogtreecommitdiffstats
path: root/builtin-count-objects.c
diff options
context:
space:
mode:
Diffstat (limited to 'builtin-count-objects.c')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-22 13:27:09 +0000
logheader'>2018-11-13rename "alternate_object_database" to "object_directory"Jeff King10-69/+69 In preparation for unifying the handling of alt odb's and the normal repo object directory, let's use a more neutral name. This patch is purely mechanical, swapping the type name, and converting any variables named "alt" to "odb". There should be no functional change, but it will reduce the noise in subsequent diffs. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-11-13submodule--helper: prefer strip_suffix() to ends_with()Jeff King1-3/+4 Using strip_suffix() lets us avoid repeating ourselves. It also makes the handling of "/" a bit less subtle (we strip one less character than we matched in order to leave it in place, but we can just as easily include the "/" when we add more path components). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-11-13fsck: do not reuse child_process structsJeff King1-0/+6 The run-command API makes no promises about what is left in a struct child_process after a command finishes, and it's not safe to simply reuse it again for a similar command. In particular: - if you use child->args or child->env_array, they are cleared after finish_command() - likewise, start_command() may point child->argv at child->args->argv; reusing that would lead to accessing freed memory - the in/out/err may hold pipe descriptors from the previous run These two calls are _probably_ OK because they do not use any of those features. But it's only by chance, and may break in the future; let's reinitialize our struct for each program we run. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-11-06Ninth batch for 2.20Junio C Hamano1-2/+57 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-11-02Eighth batch for 2.20Junio C Hamano1-0/+6 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-11-02rebase: apply cocci patchJunio C Hamano1-1/+1 Favor oideq() over !oidcmp() when checking for equality. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-30Seventh batch for 2.20Junio C Hamano1-0/+63 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-30test-lib: introduce the '-V' short option for '--verbose-log'SZEDER Gábor2-2/+3 '--verbose-log' is one of the most useful and thus most frequently used test options, but due to its length it's a pain to type on the command line. Let's introduce the corresponding short option '-V' to save some keystrokes. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-29commit-reach.h: add missing declarations (hdr-check)Ramsay Jones1-2/+3 Add the necessary #includes and forward declarations to allow the header file to pass the 'hdr-check' target. Note that, since this header includes the commit-slab implementation header file (indirectly via commit-slab.h), some of the commit-slab inline functions (e.g contains_cache_at_peek()) will not compile without the complete type of 'struct commit'. Hence, we replace the forward declaration of 'struct commit' with the an #include of the 'commit.h' header file. It is possible, using the 'commit-slab-{decl,impl}.h' files, to avoid this inclusion of the 'commit.h' header. Commit a9f1f1f9f8 ("commit-slab.h: code split", 2018-05-19) separated the commit-slab interface from its implementation, to allow for the definition of a public commit-slab data structure. This enabled us to avoid including the commit-slab implementation in a header file, which could result in the replication of the commit-slab functions in each compilation unit in which it was included. Indeed, if you compile with optimizations disabled, then run this script: $ cat -n dup-static.sh 1 #!/bin/sh 2 3 nm $1 | grep ' t ' | cut -d' ' -f3 | sort | uniq -c | 4 sort -rn | grep -v ' 1' $ $ ./dup-static.sh git | grep contains 24 init_contains_cache_with_stride 24 init_contains_cache 24 contains_cache_peek 24 contains_cache_at_peek 24 contains_cache_at 24 clear_contains_cache $ you will find 24 copies of the commit-slab routines for the contains_cache. Of course, when you enable optimizations again, these duplicate static functions (mostly) disappear. Compiling with gcc at -O2, leaves two static functions, thus: $ nm commit-reach.o | grep contains_cache 0000000000000870 t contains_cache_at_peek.isra.1.constprop.6 $ nm ref-filter.o | grep contains_cache 00000000000002b0 t clear_contains_cache.isra.14 $ However, using a shared 'contains_cache' would result in all six of the above functions as external public functions in the git binary. At present, only three of these functions are actually called, so the trade-off seems to favour letting the compiler inline the commit-slab functions. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-29ewok_rlw.h: add missing 'inline' to function definitionRamsay Jones1-1/+1 The 'ewok_rlw.h' header file contains the rlw_get_run_bit() function definition, which is marked as 'static' but not 'inline'. At least when compiled by gcc, with the default -O2 optimization level, the function is actually inlined and leaves no static version in the ewah_bitmap.o and ewah_rlw.o object files. Despite this, add the missing 'inline' keyword to better describe the intended behaviour. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-29fetch-object.h: add missing declaration (hdr-check)Ramsay Jones1-0/+2 Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-29t3404-rebase-interactive: test abbreviated commandsJohannes Sixt2-7/+7 Make sure that each short command is tested at least once. To not exacerbate the runtime of the test script, do not add new tests, but modify existing ones according to these criteria: - The test does not have a prerequisite. - The 'git rebase' command is not guarded by test_must_fail. The pick commands are optional in the FAKE_LINES variable, but when used, they do end up in the insn sheet. Test them, too. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-27sequencer: cleanup for gcc warning in non developer modeCarlo Marcelo Arenas Belón1-1/+1 as shown by: sequencer.c: In function ‘write_basic_state’: sequencer.c:2392:37: warning: zero-length gnu_printf format string [-Wformat-zero-length] write_file(rebase_path_verbose(), ""); where write_file will create an empty file if told to write an empty string as can be inferred by the previous call the somehow more convoluted syntax works around the issue by providing a non empty format string and is already being used for the abort safety file since 1e41229d96 ("sequencer: make sequencer abort safer", 2016-12-07) Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-26Sixth batch for 2.20Junio C Hamano1-0/+48 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-26travis-ci: no longer use containersSebastian Staudt1-2/+0 Travis CI will soon deprecate the container-based infrastructure enabled by `sudo: false` in ce59dffb34190e780be2fa9f449f842cadee9753. More info: https://blog.travis-ci.com/2018-10-04-combining-linux-infrastructures Signed-off-by: Sebastian Staudt <koraktor@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-26path.c: char is not (always) signedTorsten Bögershausen1-1/+1 If a "char" in C is signed or unsigned is not specified, because it is out of tradition "implementation dependent". Therefore constructs like "if (name[i] < 0)" are not portable, use "if (name[i] & 0x80)" instead. Detected by "gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516" when setting DEVELOPER = 1 DEVOPTS = extra-all Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-26http: give curl version warnings consistentlyJunio C Hamano1-4/+2 When a requested feature cannot be activated because the version of cURL library used to build Git with is too old, most of the codepaths give a warning like "$Feature is not supported with cURL < $Version", marked for l10n. A few of them, however, did not follow that pattern and said things like "$Feature is not activated, your curl version is too old (>= $Version)", and without marking them for l10n. Update these to match the style of the majority of warnings and mark them for l10n. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-26http: when using Secure Channel, ignore sslCAInfo by defaultJohannes Schindelin2-1/+26 As of cURL v7.60.0, the Secure Channel backend can use the certificate bundle provided via `http.sslCAInfo`, but that would override the Windows Certificate Store. Since this is not desirable by default, let's tell Git to not ask cURL to use that bundle by default when the `schannel` backend was configured via `http.sslBackend`, unless `http.schannelUseSSLCAInfo` overrides this behavior. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-26http: add support for disabling SSL revocation checks in cURLBrendan Forster2-0/+25 This adds support for a new http.schannelCheckRevoke config value. This config value is only used if http.sslBackend is set to "schannel", which forces cURL to use the Windows Certificate Store when validating server certificates associated with a remote server. This config value should only be set to "false" if you are in an environment where revocation checks are blocked by the network, with no alternative options. This is only supported in cURL 7.44 or later. Note: originally, we wanted to call the config setting `http.schannel.checkRevoke`. This, however, does not work: the `http.*` config settings can be limited to specific URLs via `http.<url>.*` (and this feature would mistake `schannel` for a URL). Helped by Agustín Martín Barbero. Signed-off-by: Brendan Forster <github@brendanforster.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-26upload-pack: fix broken if/else chain in config callbackJeff King1-3/+6 The upload_pack_config() callback uses an if/else chain like: if (!strcmp(var, "a")) ... else if (!strcmp(var, "b")) ... etc This works as long as the conditions are mutually exclusive, but one of them is not. 20b20a22f8 (upload-pack: provide a hook for running pack-objects, 2016-05-18) added: else if (current_config_scope() != CONFIG_SCOPE_REPO) { ... check some more options ... } That was fine in that commit, because it came at the end of the chain. But later, 10ac85c785 (upload-pack: add object filtering for partial clone, 2017-12-08) did this: else if (current_config_scope() != CONFIG_SCOPE_REPO) { ... check some more options ... } else if (!strcmp("uploadpack.allowfilter", var)) ... We'd always check the scope condition first, meaning we'd _only_ respect allowfilter when it's in the repo config. You can see this with: git -c uploadpack.allowfilter=true upload-pack . | head -1 which will not advertise the filter capability (but will after this patch). We never noticed because: - our tests always set it in the repo config - in protocol v2, we use a different code path that actually calls repo_config_get_bool() separately, so that _does_ work. Real-world people experimenting with this may be using v2. The more recent uploadpack.allowrefinwant option is in the same boat. There are a few possible fixes: 1. Bump the scope conditional back to the bottom of the chain. But that just means somebody else is likely to make the same mistake later. 2. Make the conditional more like the others. I.e.: else if (!current_config_scope() != CONFIG_SCOPE_REPO && !strcmp(var, "uploadpack.notallowedinrepo")) This works, but the idea of the original structure was that we may grow multiple sensitive options like this. 3. Pull it out of the chain entirely. The chain mostly serves to avoid extra strcmp() calls after we've found a match. But it's not worth caring about those. In the worst case, when there isn't a match, we're already hitting every strcmp (and this happens regularly for stuff like "core.bare", etc). This patch does (3). Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-26rebase -i: recognize short commands without argumentsJohannes Sixt3-3/+6 The sequencer instruction 'b', short for 'break', is rejected: error: invalid line 2: b The reason is that the parser expects all short commands to have an argument. Permit short commands without arguments. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-26archive: initialize archivers earlierJosh Steadmon6-4/+23 Initialize archivers as soon as possible when running git-archive. Various non-obvious behavior depends on having the archivers initialized, such as determining the desired archival format from the provided filename. Since 08716b3c11 ("archive: refactor file extension format-guessing", 2011-06-21), archive_format_from_filename() has used the registered archivers to match filenames (provided via --output) to archival formats. However, when git-archive is executed with --remote, format detection happens before the archivers have been registered. This causes archives from remotes to always be generated as TAR files, regardless of the actual filename (unless an explicit --format is provided). This patch fixes that behavior; archival format is determined properly from the output filename, even when --remote is used. Helped-by: Jeff King <peff@peff.net> Signed-off-by: Josh Steadmon <steadmon@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-25compat: make sure git_mmap is not expected to writeCarlo Marcelo Arenas Belón1-1/+1 in f48000fc ("Yank writing-back support from gitfakemmap.", 2005-10-08) support for writting back changes was removed but the specific prot flag that would be used was not checked for Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-25range-diff: allow to diff files regardless of submodule configLucas De Marchi2-1/+30 If we have `submodule.diff = log' in the configuration file or `--submodule=log' is given as argument, range-diff fails to compare both diffs and we only get the following output: Submodule a 0000000...0000000 (new submodule) Even if the repository doesn't have any submodule. That's because the mode in diff_filespec is not correct and when flushing the diff, down in builtin_diff() we will enter the condition: if (o->submodule_format == DIFF_SUBMODULE_LOG && (!one->mode || S_ISGITLINK(one->mode)) && (!two->mode || S_ISGITLINK(two->mode))) { show_submodule_summary(o, one->path ? one->path : two->path, &one->oid, &two->oid, two->dirty_submodule); return; It turns out that S_ISGITLINK will return true (mode == 0160000 here). Similar thing happens if submodule.diff is "diff". Do like it's done in grep.c when calling fill_filespec() and force it to be recognized as a file by adding S_IFREG to the mode. Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-25howto/using-merge-subtree: mention --allow-unrelated-historiesUwe Kleine-König1-1/+1 Without passing --allow-unrelated-histories the command sequence fails as intended since commit e379fdf34fee ("merge: refuse to create too cool a merge by default"). To setup a subtree merging unrelated histories is normal, so add the option to the howto document. Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-25doc: document diff/merge.guitool config keysDenton Liu2-0/+14 Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-25completion: support `git mergetool --[no-]gui`Denton Liu1-1/+1 Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Anmol Mago <anmolmago@gmail.com> Signed-off-by: Brian Ho <briankyho@gmail.com> Signed-off-by: David Lu <david.lu97@outlook.com> Signed-off-by: Ryan Wang <shirui.wang@hotmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-25mergetool: accept -g/--[no-]gui as argumentsDenton Liu3-7/+31 In line with how difftool accepts a -g/--[no-]gui option, make mergetool accept the same option in order to use the `merge.guitool` variable to find the default mergetool instead of `merge.tool`. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Anmol Mago <anmolmago@gmail.com> Signed-off-by: Brian Ho <briankyho@gmail.com> Signed-off-by: David Lu <david.lu97@outlook.com> Signed-off-by: Ryan Wang <shirui.wang@hotmail.com> Acked-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-25repack -ad: prune the list of shallow commitsJohannes Schindelin2-1/+7 `git repack` can drop unreachable commits without further warning, making the corresponding entries in `.git/shallow` invalid, which causes serious problems when deepening the branches. One scenario where unreachable commits are dropped by `git repack` is when a `git fetch --prune` (or even a `git fetch` when a ref was force-pushed in the meantime) can make a commit unreachable that was reachable before. Therefore it is not safe to assume that a `git repack -adlf` will keep unreachable commits alone (under the assumption that they had not been packed in the first place, which is an assumption at least some of Git's code seems to make). This is particularly important to keep in mind when looking at the `.git/shallow` file: if any commits listed in that file become unreachable, it is not a problem, but if they go missing, it *is* a problem. One symptom of this problem is that a deepening fetch may now fail with fatal: error in object: unshallow <commit-hash> To avoid this problem, let's prune the shallow list in `git repack` when the `-d` option is passed, unless `-A` is passed, too (which would force the now-unreachable objects to be turned into loose objects instead of being deleted). Additionally, we also need to take `--keep-reachable` and `--unpack-unreachable=<date>` into account. Note: an alternative solution discussed during the review of this patch was to teach `git fetch` to simply ignore entries in .git/shallow if the corresponding commits do not exist locally. A quick test, however, revealed that the .git/shallow file is written during a shallow *clone*, in which case the commits do not exist, either, but the "shallow" line *does* need to be sent. Therefore, this approach would be a lot more finicky than the approach presented by the this patch. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-25shallow: offer to prune only non-existing entriesJohannes Schindelin3-8/+21 The `prune_shallow()` function wants a full reachability check to be completed before it goes to work, to ensure that all unreachable entries are removed from the shallow file. However, in the upcoming patch we do not even want to go that far. We really only need to remove entries corresponding to pruned commits, i.e. to commits that no longer exist. Let's support that use case. Rather than extending the signature of `prune_shallow()` to accept another Boolean, let's turn it into a bit field and declare constants, for readability. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-25repack: point out a bug handling stale shallow infoJohannes Schindelin1-0/+27 A `git fetch --prune` can turn previously-reachable objects unreachable, even commits that are in the `shallow` list. A subsequent `git repack -ad` will then unceremoniously drop those unreachable commits, and the `shallow` list will become stale. This means that when we try to fetch with a larger `--depth` the next time, we may end up with: fatal: error in object: unshallow <commit-hash> Reported by Alejandro Pauly. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-25t5410: use longer path for sample scriptJeff King1-1/+1 t5410 creates a sample script "alternate-refs", and sets core.alternateRefsCommand to just "alternate-refs". That shouldn't work, as "." is not in our $PATH, and so we should not find it. However, due to a bug in run-command.c, we sometimes find it anyway! Even more confusing, this bug is only in the fork-based version of run-command. So the test passes on Linux (etc), but fails on Windows. In preparation for fixing the run-command bug, let's use a more complete path here. Reported-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-25run-command: mark path lookup errors with ENOENTJeff King2-5/+29 Since commit e3a434468f (run-command: use the async-signal-safe execv instead of execvp, 2017-04-19), prepare_cmd() does its own PATH lookup for any commands we run (on non-Windows platforms). However, its logic does not match the old execvp call when we fail to find a matching entry in the PATH. Instead of feeding the name directly to execv, execvp would consider that an ENOENT error. By continuing and passing the name directly to execv, we effectively behave as if "." was included at the end of the PATH. This can have confusing and even dangerous results. The fix itself is pretty straight-forward. There's a new test in t0061 to cover this explicitly, and I've also added a duplicate of the ENOENT test to ensure that we return the correct errno for this case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-24khash: silence -Wunused-function for delta-islandsCarlo Marcelo Arenas Belón1-1/+1 showing the following when compiled with latest clang (OpenBSD, Fedors and macOS): delta-islands.c:23:1: warning: unused function 'kh_destroy_str' [-Wunused-function] delta-islands.c:23:1: warning: unused function 'kh_clear_str' [-Wunused-function] delta-islands.c:23:1: warning: unused function 'kh_del_str' [-Wunused-function] Reported-by: René Scharfe <l.s.r@web.de> Suggested-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-24commit-slabs: move MAYBE_UNUSED outCarlo Marcelo Arenas Belón2-2/+4 after 36da893114 ("config.mak.dev: enable -Wunused-function", 2018-10-18) it is expected to be used to prevent -Wunused-function warnings for code that was macro generated Signed-off-by: Carlo Marcelo Arenas Belón <carenas@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-24mingw: fix getcwd when the parent directory cannot be queriedAnton Serbulov1-0/+39 `GetLongPathName()` function may fail when it is unable to query the parent directory of a path component to determine the long name for that component. It happens, because it uses `FindFirstFile()` function for each next short part of path. The `FindFirstFile()` requires `List Directory` and `Synchronize` desired access for a calling process. In case of lacking such permission for some part of path, the `GetLongPathName()` returns 0 as result and `GetLastError()` returns ERROR_ACCESS_DENIED. `GetFinalPathNameByHandle()` function can help in such cases, because it requires `Read Attributes` and `Synchronize` desired access to the target path only. The `GetFinalPathNameByHandle()` function was introduced on `Windows Server 2008/Windows Vista`. So we need to load it dynamically. `CreateFile()` parameters: `lpFileName` = path to the current directory `dwDesiredAccess` = 0 (it means `Read Attributes` and `Synchronize`) `dwShareMode` = FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE (it prevents `Sharing Violation`) `lpSecurityAttributes` = NULL (default security attributes) `dwCreationDisposition` = OPEN_EXISTING (required to obtain a directory handle) `dwFlagsAndAttributes` = FILE_FLAG_BACKUP_SEMANTICS (required to obtain a directory handle) `hTemplateFile` = NULL (when opening an existing file or directory, `CreateFile` ignores this parameter) The string that is returned by `GetFinalPathNameByHandle()` function uses the \\?\ syntax. To skip the prefix and convert backslashes to slashes, the `normalize_ntpath()` mingw function will be used. Note: `GetFinalPathNameByHandle()` function returns a final path. It is the path that is returned when a path is fully resolved. For example, for a symbolic link named "C:\tmp\mydir" that points to "D:\yourdir", the final path would be "D:\yourdir". Signed-off-by: Anton Serbulov <aserbulov@plesk.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-24mingw: ensure `getcwd()` reports the correct caseJohannes Schindelin1-2/+9 When switching the current working directory, say, in PowerShell, it is quite possible to use a different capitalization than the one that is recorded on disk. While doing the same in `cmd.exe` adjusts the capitalization magically, that does not happen in PowerShell so that `getcwd()` returns the current directory in a different way than is recorded on disk. Typically this creates no problems except when you call git log . in a subdirectory called, say, "GIT/" but you switched to "Git/" and your `getcwd()` reports the latter, then Git won't understand that you wanted to see the history as per the `GIT/` subdirectory but it thinks you wanted to see the history of some directory that may have existed in the past (but actually never did). So let's be extra careful to adjust the capitalization of the current directory before working with it. Reported by a few PowerShell power users ;-) Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-24mingw: load system libraries the recommended wayJohannes Schindelin2-2/+4 When we access IPv6-related functions, we load the corresponding system library using the `LoadLibrary()` function, which is not the recommended way to load system libraries. In practice, it does not make a difference: the `ws2_32.dll` library containing the IPv6 functions is already loaded into memory, so LoadLibrary() simply reuses the already-loaded library. Still, recommended way is recommended way, so let's use that instead. While at it, also adjust the code in contrib/ that loads system libraries. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-24rebase --autostash: fix issue with dirty submodulesJohannes Schindelin2-2/+2 Since we cannot stash dirty submodules, there is no use in requiring them to be clean (or stash them when they are not). This brings the built-in rebase in line with the previous, scripted version, which also did not care about dirty submodules (but it was admittedly not very easy to figure that out). This fixes https://github.com/git-for-windows/git/issues/1820 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-24rebase --autostash: demonstrate a problem with dirty submodulesJohannes Schindelin1-0/+10 It has been reported that dirty submodules cause problems with the built-in rebase when it is asked to autostash. The symptom is: fatal: Unexpected stash response: '' This patch adds a regression test that demonstrates that bug. Original report: https://github.com/git-for-windows/git/issues/1820 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-24mingw: implement nanosecond-precision file timesKarsten Blees3-20/+36 We no longer use any of MSVCRT's stat-functions, so there's no need to stick to a CRT-compatible 'struct stat' either. Define and use our own POSIX-2013-compatible 'struct stat' with nanosecond- precision file times. Note: This can cause performance issues when using Git variants with different file time resolutions, as the timestamps are stored in the Git index: after updating the index with a Git variant that uses second-precision file times, a nanosecond-aware Git will think that pretty much every single file listed in the index is out of date. Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-24mingw: replace MSVCRT's fstat() with a Win32-based implementationKarsten Blees1-10/+21 fstat() is the only stat-related CRT function for which we don't have a full replacement yet (and thus the only reason to stick with MSVCRT's 'struct stat' definition). Fully implement fstat(), in preparation of implementing a POSIX 2013 compatible 'struct stat' with nanosecond-precision file times. This allows us also to implement some clever code to handle pipes and character devices in our own way. Signed-off-by: Karsten Blees <blees@dcon.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-24mingw: factor out code to set stat() dataJohannes Schindelin1-14/+25 In our fstat() emulation, we convert the file metadata from Win32 data structures to an emulated POSIX structure. To structure the code better, let's factor that part out into its own function. Note: it would be tempting to try to unify this code with the part of do_lstat() that does the same thing, but they operate on different data structures: BY_HANDLE_FILE_INFORMATION vs WIN32_FILE_ATTRIBUTE_DATA. So unfortunately, they cannot be unified. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-24Documentation/config.txt: fix typo in core.alternateRefsCommandTaylor Blau1-1/+1 In [1] Git learned about 'core.alternateRefsCommand', and with it, the accompanying documentation. However, this documentation included a typo involving the verb tense of "produced". Match the tense of the surrounding bits by correcting this typo. [1]: 89284c1d6c (transport.c: introduce core.alternateRefsCommand, 2018-10-08) Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2018-10-24fsck: s/++i > 1/i++/Junio C Hamano1-1/+1 Signed-off-by: Junio C Hamano <gitster@pobox.com>