Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.kernel.org/pub/scm/git/git.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)Author
2023-03-21treewide: remove unnecessary cache.h inclusion from a few headersElijah Newren
Ever since a64215b6cd ("object.h: stop depending on cache.h; make cache.h depend on object.h", 2023-02-24), we have a few headers that could have replaced their include of cache.h with an include of object.h. Make that change now. Some C files had to start including cache.h after this change (or some smaller header it had brought in), because the C files were depending on things from cache.h but were only formerly implicitly getting cache.h through one of these headers being modified in this patch. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-20Merge branch 'jk/add-p-unmerged-fix'Junio C Hamano
"git add -p" while the index is unmerged sometimes failed to parse the diff output it internally produces and died, which has been corrected. * jk/add-p-unmerged-fix: add-patch: handle "* Unmerged path" lines
2023-03-20Merge branch 'ew/fetch-no-write-fetch-head-fix'Junio C Hamano
* ew/fetch-no-write-fetch-head-fix: fetch: pass --no-write-fetch-head to subprocesses
2023-03-20Merge branch 'ab/fix-strategy-opts-parsing'Junio C Hamano
The code to parse "git rebase -X<opt>" was not prepared to see an unparsable option string, which has been corrected. * ab/fix-strategy-opts-parsing: sequencer.c: fix overflow & segfault in parse_strategy_opts()
2023-03-20Merge branch 'jk/format-patch-change-format-for-empty-commits'Junio C Hamano
"git format-patch" learned to write a log-message only output file for empty commits. * jk/format-patch-change-format-for-empty-commits: format-patch: output header for empty commits
2023-03-20Merge branch 'jk/bundle-use-dash-for-stdfiles'Junio C Hamano
"git bundle" learned that "-" is a common way to say that the input comes from the standard input and/or the output goes to the standard output. It used to work only for output and only from the root level of the working tree. * jk/bundle-use-dash-for-stdfiles: parse-options: use prefix_filename_except_for_dash() helper parse-options: consistently allocate memory in fix_filename() bundle: don't blindly apply prefix_filename() to "-" bundle: document handling of "-" as stdin bundle: let "-" mean stdin for reading operations
2023-03-20Merge branch 'jk/bundle-progress'Junio C Hamano
Simplify UI to control progress meter given by "git bundle" command. * jk/bundle-progress: bundle: turn on --all-progress-implied by default
2023-03-20Merge branch 'rj/avoid-switching-to-already-used-branch'Junio C Hamano
A few subcommands have been taught to stop users from working on a branch that is being used in another worktree linked to the same repository. * rj/avoid-switching-to-already-used-branch: switch: reject if the branch is already checked out elsewhere (test) rebase: refuse to switch to a branch already checked out elsewhere (test) branch: fix die_if_checked_out() when ignore_current_worktree worktree: introduce is_shared_symref()
2023-03-20Merge branch 'rj/bisect-already-used-branch'Junio C Hamano
Allow "git bisect reset" to check out the original branch when the branch is already checked out in a different worktree linked to the same repository. * rj/bisect-already-used-branch: bisect: fix "reset" when branch is checked out elsewhere
2023-03-20Merge branch 'zh/push-to-delete-onelevel-ref'Junio C Hamano
"git push" has been taught to allow deletion of refs with one-level names to help repairing a repository who acquired such a ref by mistake. In general, we don't encourage use of such a ref, and creation or update to such a ref is rejected as before. * zh/push-to-delete-onelevel-ref: push: allow delete single-level ref receive-pack: fix funny ref error messsage
2023-03-20Merge branch 'ak/restore-both-incompatible-with-conflicts'Junio C Hamano
"git restore" supports options like "--ours" that are only meaningful during a conflicted merge, but these options are only meaningful when updating the working tree files. These options are marked to be incompatible when both "--staged" and "--worktree" are in effect. * ak/restore-both-incompatible-with-conflicts: restore: fault --staged --worktree with merge opts
2023-03-20Merge branch 'ab/avoid-losing-exit-codes-in-tests'Junio C Hamano
Test clean-up. * ab/avoid-losing-exit-codes-in-tests: tests: don't lose misc "git" exit codes tests: don't lose exit status with "test <op> $(git ...)" tests: don't lose "git" exit codes in "! ( git ... | grep )" tests: don't lose exit status with "(cd ...; test <op> $(git ...))" t/lib-patch-mode.sh: fix ignored exit codes auto-crlf tests: don't lose exit code in loops and outside tests
2023-03-18Merge branch 'ew/fetch-hiderefs'Junio C Hamano
A new "fetch.hideRefs" option can be used to exclude specified refs from "rev-list --objects --stdin --not --all" traversal for checking object connectivity, most useful when there are many unrelated histories in a single repository. * ew/fetch-hiderefs: fetch: support hideRefs to speed up connectivity checks
2023-03-18Merge branch 'mc/credential-helper-www-authenticate'Junio C Hamano
Allow information carried on the WWW-AUthenticate header to be passed to the credential helpers. * mc/credential-helper-www-authenticate: credential: add WWW-Authenticate header to cred requests http: read HTTP WWW-Authenticate response headers t5563: add tests for basic and anoymous HTTP access
2023-03-18Merge branch 'jc/gpg-lazy-init'Junio C Hamano
Instead of forcing each command to choose to honor GPG related configuration variables, make the subsystem lazily initialize itself. * jc/gpg-lazy-init: drop pure pass-through config callbacks gpg-interface: lazily initialize and read the configuration
2023-03-18Merge branch 'jk/unused-post-2.39-part2'Junio C Hamano
More work towards -Wunused. * jk/unused-post-2.39-part2: (21 commits) help: mark unused parameter in git_unknown_cmd_config() run_processes_parallel: mark unused callback parameters userformat_want_item(): mark unused parameter for_each_commit_graft(): mark unused callback parameter rewrite_parents(): mark unused callback parameter fetch-pack: mark unused parameter in callback function notes: mark unused callback parameters prio-queue: mark unused parameters in comparison functions for_each_object: mark unused callback parameters list-objects: mark unused callback parameters mark unused parameters in signal handlers run-command: mark error routine parameters as unused mark "pointless" data pointers in callbacks ref-filter: mark unused callback parameters http-backend: mark unused parameters in virtual functions http-backend: mark argc/argv unused object-name: mark unused parameters in disambiguate callbacks serve: mark unused parameters in virtual functions serve: use repository pointer to get config ls-refs: drop config caching ...
2023-03-18Merge branch 'en/header-cleanup'Junio C Hamano
Code clean-up to clarify the rule that "git-compat-util.h" must be the first to be included. * en/header-cleanup: diff.h: remove unnecessary include of object.h Remove unnecessary includes of builtin.h treewide: replace cache.h with more direct headers, where possible replace-object.h: move read_replace_refs declaration from cache.h to here object-store.h: move struct object_info from cache.h dir.h: refactor to no longer need to include cache.h object.h: stop depending on cache.h; make cache.h depend on object.h ident.h: move ident-related declarations out of cache.h pretty.h: move has_non_ascii() declaration from commit.h cache.h: remove dependence on hex.h; make other files include it explicitly hex.h: move some hex-related declarations from cache.h hash.h: move some oid-related declarations from cache.h alloc.h: move ALLOC_GROW() functions from cache.h treewide: remove unnecessary cache.h includes in source files treewide: remove unnecessary cache.h includes treewide: remove unnecessary git-compat-util.h includes in headers treewide: ensure one of the appropriate headers is sourced first
2023-03-18Merge branch 'en/dir-api-cleanup'Junio C Hamano
Code clean-up to clarify directory traversal API. * en/dir-api-cleanup: unpack-trees: add usage notices around df_conflict_entry unpack-trees: special case read-tree debugging as internal usage unpack-trees: rewrap a few overlong lines from previous patch unpack-trees: mark fields only used internally as internal unpack_trees: start splitting internal fields from public API sparse-checkout: avoid using internal API of unpack-trees, take 2 sparse-checkout: avoid using internal API of unpack-trees unpack-trees: clean up some flow control dir: mark output only fields of dir_struct as such dir: add a usage note to exclude_per_dir dir: separate public from internal portion of dir_struct unpack-trees: heed requests to overwrite ignored files t2021: fix platform-specific leftover cruft
2023-03-18Merge branch 'jk/fsck-indices-in-worktrees'Junio C Hamano
"git fsck" learned to check the index files in other worktrees, just like "git gc" honors them as anchoring points. * jk/fsck-indices-in-worktrees: fsck: check even zero-entry index files fsck: mention file path for index errors fsck: check index files in all worktrees fsck: factor out index fsck
2023-03-09fetch: pass --no-write-fetch-head to subprocessesEric Wong
It seems a user would expect this option would work regardless of whether it's fetching from a single remote, many remotes, or recursing into submodules. Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-09add-patch: handle "* Unmerged path" linesJeff King
When we generate a diff with --cached, unmerged entries have no oid for their index entry: $ git diff-index --abbrev --cached HEAD :100644 000000 f719efd 0000000 U my-conflict So when we are asked to produce a patch, since we only have one side, we just emit a special message: $ git diff-index --cached -p HEAD * Unmerged path my-conflict This confuses interactive-patch modes that look at cached diffs. For example: $ git reset -p BUG: add-patch.c:498: diff starts with unexpected line: * Unmerged path my-conflict Making things even more confusing, you'll get that error only if the unmerged entry is alphabetically the first changed file. Otherwise, we simply stick the unrecognized line to the end of the previous hunk. There it's mostly harmless, as it eventually gets fed back to "git apply", which happily ignores it. But it's still shown to the user attached to the hunk, which is wrong. So let's handle these lines as a noop. There's not really anything useful to do with a conflicted merge in this case, and that's what we do for other cases like "add -p". There we get a "diff --cc" line, which we accept as starting a new file, but we refuse to use any of its hunks (their headers start with "@@@" and not "@@ ", so we silently ignore them). It seems like simply recognizing the line and continuing in our parsing loop would work. But we actually need to run the rest of the loop body to handle matching up our colored/filtered output. But that code assumes that we have some active file_diff we're working on. So instead, we'll just insert a dummy entry into our array. This ends up the same as if we saw a "diff --cc" line (a file with no hunks). Reported-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-09sequencer.c: fix overflow & segfault in parse_strategy_opts()Ævar Arnfjörð Bjarmason
The split_cmdline() function introduced in [1] returns an "int". If it's negative it signifies an error. The option parsing in [2] didn't account for this, and assigned the value directly to the "size_t xopts_nr". We'd then attempt to loop over all of these elements, and access uninitialized memory. There's a few things that use this for option parsing, but one way to trigger it is with a bad value to "-X <strategy-option>", e.g: git rebase -X"bad argument\"" In another context this might be a security issue, but in this case someone who's already able to inject arguments directly to our commands would be past other defenses, making this potential escalation a moot point. As the example above & test case shows the error reporting leaves something to be desired. The function will loop over the whitespace-split values, but when it encounters an error we'll only report the first element, which is OK, not the second "argument\"" whose quote is unbalanced. This is an inherent limitation of the current API, and the issue affects other API users. Let's not attempt to fix that now. If and when that happens these tests will need to be adjusted to assert the new output. 1. 2b11e3170e9 (If you have a config containing something like this:, 2006-06-05) 2. ca6c6b45dd9 (sequencer (rebase -i): respect strategy/strategy_opts settings, 2017-01-02) Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-07parse-options: consistently allocate memory in fix_filename()Jeff King
When handling OPT_FILENAME(), we have to stick the "prefix" (if any) in front of the filename to make up for the fact that Git has chdir()'d to the top of the repository. We can do this with prefix_filename(), but there are a few special cases we handle ourselves. Unfortunately the memory allocation is inconsistent here; if we do make it to prefix_filename(), we'll allocate a string which the caller must free to avoid a leak. But if we hit our special cases, we'll return the string as-is, and a caller which tries to free it will crash. So there's no way to win. Let's consistently allocate, so that callers can do the right thing. There are now three cases to care about in the function (and hence a three-armed if/else): 1. we got a NULL input (and should leave it as NULL, though arguably this is the sign of a bug; let's keep the status quo for now and we can pick at that scab later) 2. we hit a special case that means we leave the name intact; we should duplicate the string. This includes our special "-" matching. Prior to this patch, it also included empty prefixes and absolute filenames. But we can observe that prefix_filename() already handles these, so we don't need to detect them. 3. everything else goes to prefix_filename() I've dropped the "const" from the "char **file" parameter to indicate that we're allocating, though in practice it's not really important. This is all being shuffled through a void pointer via opt->value before it hits code which ever looks at the string. And it's even a bit weird, because we are really taking _in_ a const string and using the same out-parameter for a non-const string. A better function signature would be: static char *fix_filename(const char *prefix, const char *file); but that would mean the caller dereferences the double-pointer (and the NULL check is currently handled inside this function). So I took the path of least-change here. Note that we have to fix several callers in this commit, too, or we'll break the leak-checking tests. These are "new" leaks in the sense that they are now triggered by the test suite, but these spots have always been leaky when Git is run in a subdirectory of the repository. I fixed all of the cases that trigger with GIT_TEST_PASSING_SANITIZE_LEAK. There may be others in scripts that have other leaks, but we can fix them later along with those other leaks (and again, you _couldn't_ fix them before this patch, so this is the necessary first step). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-07bundle: don't blindly apply prefix_filename() to "-"Junio C Hamano
A user can specify a filename to a command from the command line, either as the value given to a command line option, or a command line argument. When it is given as a relative filename, in the user's mind, it is relative to the directory "git" was started from, but by the time the filename is used, "git" would almost always have chdir()'ed up to the root level of the working tree. The given filename, if it is relative, needs to be prefixed with the path to the current directory, and it typically is done by calling prefix_filename() helper function. For commands that can also take "-" to use the standard input or the standard output, however, this needs to be done with care. "git bundle create" uses the next word on the command line as the output filename, and can take "-" to mean "write to the standard output". It blindly called prefix_filename(), so running it in a subdirectory did not quite work as expected. Introduce a new helper, prefix_filename_except_for_dash(), and use it to help "git bundle create" codepath. Reported-by: Michael Henry Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-07bundle: let "-" mean stdin for reading operationsJeff King
For writing, "bundle create -" indicates that the bundle should be written to stdout. But there's no matching handling of "-" for reading operations. This is inconsistent, and a little inflexible (though one can always use "/dev/stdin" on systems that support it). However, it's easy to change. Once upon a time, the bundle-reading code required a seekable descriptor, but that was fixed long ago in e9ee84cf28b (bundle: allowing to read from an unseekable fd, 2011-10-13). So we just need to handle "-" explicitly when opening the file. We _could_ do this by handling "-" in read_bundle_header(), which the reading functions all call already. But that is probably a bad idea. It's also used by low-level code like the transport functions, and we may want to be more careful there. We do not know that stdin is even available to us, and certainly we would not want to get confused by a configured URL that happens to point to "-". So instead, let's add a helper to builtin/bundle.c. Since both the bundle code and some of the callers refer to the bundle by name for error messages, let's use the string "<stdin>" to make the output a bit nicer to read. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-06bundle: turn on --all-progress-implied by defaultJeff King
In 79862b6b77c (bundle-create: progress output control, 2019-11-10), "bundle create" learned about the --all-progress and --all-progress-implied options, which were copied from pack-objects. I think these were a mistake. In pack-objects, "all-progress-implied" is about switching the behavior between a regular on-disk "git repack" and the use of pack-objects for push/fetch (where a fetch does not want progress from the server during the write stage; the client will print progress as it receives the data). But there's no such distinction for bundles. Prior to 79862b6b77c, we always printed the write stage. Afterwards, a vanilla: git bundle create foo.bundle omits the write progress, appearing to hang (especially if your repository is large or your disk is slow). That seems like a regression. It's possible that the flexibility to disable the write-phase progress _could_ be useful for bundle. E.g., if you did something like: ssh some-host git bundle create foo.bundle | git bundle unbundle But if you are running both in real-time, why are you using bundles in the first place? You're better off doing a real fetch. But even if we did want to support that, it should be the exception, and vanilla "bundle create" should display the full progress. So we'd want to name the option "--no-write-progress" or something. The "--all-progress" option itself is even worse. It exists in pack-objects only for historical reasons. It's a mistake because it implies "--progress", and we added "--all-progress-implied" to fix that. There is no reason to propagate that mistake to new commands. Likewise, the documentation for these options was pulled from pack-objects. But it doesn't make any sense in this context. It talks about "--stdout", but that is not even an option that git-bundle supports. This patch flips the default for "--all-progress-implied" back to "true", fixing the regression in 79862b6b77c. This turns that option into a noop, and means that "--all-progress" is really the same as "--progress". We _could_ drop them completely, but since they've been shipped with Git since v2.25.0, it's polite to continue accepting them. I didn't implement any sort of "--no-write-progress" here. I'm not at all convinced it's necessary, and the discussion from the original thread: https://lore.kernel.org/git/20191110204126.30553-2-robbat2@gentoo.org/ shows that that the main focus was on getting --progress and --quiet support, and not any kind of clever "real-time bundle over the network" feature. But technically this patch is making it impossible to do something that you _could_ do post-79862b6b77c. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-03format-patch: output header for empty commitsJohn Keeping
When formatting an empty commit, it is surprising that a totally empty file is generated. Set the flag to always print the header, matching the behaviour of git-log. Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-01push: allow delete single-level refZheNing Hu
We discourage the creation/update of single-level refs because some upper-layer applications only work in specified reference namespaces, such as "refs/heads/*" or "refs/tags/*", these single-level refnames may not be recognized. However, we still hope users can delete them which have been created by mistake. Therefore, when updating branches on the server with "git receive-pack", by checking whether it is a branch deletion operation, it will determine whether to allow the update of a single-level refs. This avoids creating/updating such single-level refs, but allows them to be deleted. On the client side, "git push" also does not properly fill in the old-oid of single-level refs, which causes the server-side "git receive-pack" to think that the ref's old-oid has changed when deleting single-level refs, this causes the push to be rejected. So the solution is to fix the client to be able to delete single-level refs by properly filling old-oid. Signed-off-by: ZheNing Hu <adlternative@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-03-01Merge branch 'ar/test-lib-remove-stale-comment'Junio C Hamano
Test library clean-up. * ar/test-lib-remove-stale-comment: test-lib: drop comment about test_description
2023-03-01Merge branch 'zy/t9700-style'Junio C Hamano
Test style fixes. * zy/t9700-style: t9700: modernize test scripts
2023-03-01Merge branch 'pw/rebase-i-parse-fix'Junio C Hamano
Fixes to code that parses the todo file used in "rebase -i". * pw/rebase-i-parse-fix: rebase -i: fix parsing of "fixup -C<commit>" rebase -i: match whole word in is_command()
2023-03-01Merge branch 'jk/http-test-fixes'Junio C Hamano
Various fix-ups on HTTP tests. * jk/http-test-fixes: t5559: make SSL/TLS the default t5559: fix test failures with LIB_HTTPD_SSL t/lib-httpd: enable HTTP/2 "h2" protocol, not just h2c t/lib-httpd: respect $HTTPD_PROTO in expect_askpass() t5551: drop curl trace lines without headers t5551: handle v2 protocol in cookie test t5551: simplify expected cookie file t5551: handle v2 protocol in upload-pack service test t5551: handle v2 protocol when checking curl trace t5551: stop forcing clone to run with v0 protocol t5551: handle HTTP/2 when checking curl trace t5551: lower-case headers in expected curl trace t5551: drop redundant grep for Accept-Language t5541: simplify and move "no empty path components" test t5541: stop marking "used receive-pack service" test as v0 only t5541: run "used receive-pack service" test earlier
2023-02-27credential: add WWW-Authenticate header to cred requestsMatthew John Cheetham
Add the value of the WWW-Authenticate response header to credential requests. Credential helpers that understand and support HTTP authentication and authorization can use this standard header (RFC 2616 Section 14.47 [1]) to generate valid credentials. WWW-Authenticate headers can contain information pertaining to the authority, authentication mechanism, or extra parameters/scopes that are required. The current I/O format for credential helpers only allows for unique names for properties/attributes, so in order to transmit multiple header values (with a specific order) we introduce a new convention whereby a C-style array syntax is used in the property name to denote multiple ordered values for the same property. In this case we send multiple `wwwauth[]` properties where the order that the repeated attributes appear in the conversation reflects the order that the WWW-Authenticate headers appeared in the HTTP response. Add a set of tests to exercise the HTTP authentication header parsing and the interop with credential helpers. Credential helpers will receive WWW-Authenticate information in credential requests. [1] https://datatracker.ietf.org/doc/html/rfc2616#section-14.47 Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-27t5563: add tests for basic and anoymous HTTP accessMatthew John Cheetham
Add a test showing simple anoymous HTTP access to an unprotected repository, that results in no credential helper invocations. Also add a test demonstrating simple basic authentication with simple credential helper support. Leverage a no-parsed headers (NPH) CGI script so that we can directly control the HTTP responses to simulate a multitude of good, bad and ugly remote server implementations around auth. Signed-off-by: Matthew John Cheetham <mjcheetham@outlook.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-27Merge branch 'jc/countermand-format-attach'Junio C Hamano
The format.attach configuration variable lacked a way to override a value defined in a lower-priority configuration file (e.g. the system one) by redefining it in a higher-priority configuration file. Now, setting format.attach to an empty string means show the patch inline in the e-mail message, without using MIME attachment. This is a backward incompatible change. * jc/countermand-format-attach: format.attach: allow empty value to disable multi-part messages
2023-02-27Merge branch 'jk/shorten-unambiguous-ref-wo-sscanf'Junio C Hamano
sscanf(3) used in "git symbolic-ref --short" implementation found to be not working reliably on macOS in UTF-8 locales. Rewrite the code to avoid sscanf() altogether to work it around. * jk/shorten-unambiguous-ref-wo-sscanf: shorten_unambiguous_ref(): avoid sscanf() shorten_unambiguous_ref(): use NUM_REV_PARSE_RULES constant shorten_unambiguous_ref(): avoid integer truncation
2023-02-27Merge branch 'mh/credential-password-expiry'Junio C Hamano
The credential subsystem learned that a password may have an explicit expiration. * mh/credential-password-expiry: credential: new attribute password_expiry_utc
2023-02-27Merge branch 'rs/archive-mtime'Junio C Hamano
"git archive HEAD^{tree}" records the paths with the current timestamp in the archive, making it harder to obtain a stable output. The command learned the --mtime option to specify an arbitrary timestamp (e.g. --mtime="@0 +0000" for the epoch). * rs/archive-mtime: archive: add --mtime
2023-02-27Merge branch 'tb/drop-dir-iterator-follow-symlink-bit'Junio C Hamano
Remove leftover and unused code. * tb/drop-dir-iterator-follow-symlink-bit: t0066: drop setup of "dir5" dir-iterator: drop unused `DIR_ITERATOR_FOLLOW_SYMLINKS`
2023-02-27Merge branch 'tl/range-diff-custom-abbrev'Junio C Hamano
"git range-diff" learned --abbrev=<num> option. * tl/range-diff-custom-abbrev: range-diff: let '--abbrev' option takes effect
2023-02-27Merge branch 'ap/t2015-style-update'Junio C Hamano
Test clean-up. * ap/t2015-style-update: t2015-checkout-unborn.sh: changes the style for cd
2023-02-27Merge branch 'jc/diff-algo-attribute'Junio C Hamano
The "diff" drivers specified by the "diff" attribute attached to paths can now specify which algorithm (e.g. histogram) to use. * jc/diff-algo-attribute: diff: teach diff to read algorithm from diff driver diff: consolidate diff algorithm option parsing
2023-02-27Merge branch 'pw/rebase-i-validate-labels-early'Junio C Hamano
An invalid label or ref in the "rebase -i" todo file used to trigger an runtime error. SUch an error is now diagnosed while the todo file is parsed. * pw/rebase-i-validate-labels-early: rebase -i: check labels and refs when parsing todo list
2023-02-27restore: fault --staged --worktree with merge optsAndy Koppe
The 'restore' command already rejects the --merge, --conflict, --ours and --theirs options when combined with --staged, but accepts them when --worktree is added as well. Unfortunately that doesn't appear to do anything useful. The --ours and --theirs options seem to be ignored when both --staged and --worktree are given, whereas with --merge or --conflict, the command has the same effect as if the --staged option wasn't present. So reject those options with '--staged --worktree' as well, using opts->accept_ref to distinguish restore from checkout. Add test for both '--staged' and '--staged --worktree'. Signed-off-by: Andy Koppe <andy.koppe@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-27fetch: support hideRefs to speed up connectivity checksEric Wong
With roughly 800 remotes all fetching into their own refs/remotes/$REMOTE/* island, the connectivity check[1] gets expensive for each fetch on systems which lack sufficient RAM to cache objects. To do a no-op fetch on one $REMOTE out of hundreds, hideRefs now allows the no-op fetch to take ~30 seconds instead of ~20 minutes on a noisy, RAM-constrained machine (localhost, so no network latency): git -c fetch.hideRefs=refs \ -c fetch.hideRefs='!refs/remotes/$REMOTE/' \ fetch $REMOTE [1] `git rev-list --objects --stdin --not --all --quiet --alternate-refs' Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-27test-lib: drop comment about test_descriptionAndrei Rybak
When a comment describing how each test file should start was added in commit [1], it was the second comment of t/test-lib.sh. The comment describes how variable "test_description" is supposed to be assigned at the top of each test file and how "test-lib.sh" should be used by sourcing it. However, even in [1], the comment was ten lines away from the usage of the variable by test-lib.sh. Since then, the comment has drifted away both from the top of the file and from the usage of the variable. The comment just sits in the middle of the initialization of the test library, surrounded by unrelated code, almost one hundred lines away from the usage of "test_description". Nobody has noticed this drift during evolution of test-lib.sh, which suggests that this comment has outlived its usefulness. The assignment of "test_description", sourcing of "test-lib.sh" by tests, and the process of writing tests in general are described in detail in "t/README". So drop the obsolete comment. An alternative solution could be to move the comment either to the top of the file, or down to the usage of variable "test_description". [1] e1970ce43a ("[PATCH 1/2] Test framework take two.", 2005-05-13) Signed-off-by: Andrei Rybak <rybak.a.v@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-27unpack-trees: heed requests to overwrite ignored filesElijah Newren
When a directory exists but has only ignored files within it and we are trying to switch to a branch that has a file where that directory is, the behavior depends upon --[no]-overwrite-ignore. If the user wants to --overwrite-ignore (the default), then we should delete the ignored file and directory and switch to the new branch. The code to handle this in verify_clean_subdirectory() in unpack-trees tried to handle this via paying attention to the exclude_per_dir setting of the internal dir field. This came from commit c81935348b ("Fix switching to a branch with D/F when current branch has file D.", 2007-03-15), which pre-dated 039bc64e88 ("core.excludesfile clean-up", 2007-11-14), and thus did not pay attention to ignore patterns from other relevant files. Change it to use setup_standard_excludes() so that it is also aware of excludes specified in other locations. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-27t2021: fix platform-specific leftover cruftElijah Newren
t2021.6 existed to test the status of a symlink that was left around by previous tests. It tried to also clean up the symlink after it was done so that subsequent tests wouldn't be tripped up by it. Unfortunately, since this test had a SYMLINK prerequisite, that made the cleanup platform dependent...and made a testcase I was trying to add to this testsuite fail (that testcase will be included in the next patch). Before we go and add new testcases, fix this cleanup by moving it into a separate test. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-26switch: reject if the branch is already checked out elsewhere (test)Rubén Justo
Since 5883034 (checkout: reject if the branch is already checked out elsewhere) in normal use, we do not allow multiple worktrees having the same checked out branch. A bug has recently been fixed that caused this to not work as expected. Let's add a test to notice if this changes in the future. Signed-off-by: Rubén Justo <rjusto@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2023-02-26rebase: refuse to switch to a branch already checked out elsewhere (test)Rubén Justo
In b5cabb4a9 (rebase: refuse to switch to branch already checked out elsewhere, 2020-02-23) we add a condition to prevent a rebase operation involving a switch to a branch that is already checked out in another worktree. A bug has recently been fixed that caused this to not work as expected. Let's add a test to notice if this changes in the future. Signed-off-by: Rubén Justo <rjusto@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>