summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2020-03-28midx.c: fix an integer underflowLibravatar Damien Robert2-4/+9
When verifying a midx index with 0 objects, the m->num_objects - 1 underflows and wraps around to 4294967295. Fix this both by checking that the midx contains at least one oid, and also that we don't write any midx when there is no packfiles. Update the tests to check that `git multi-pack-index write` does not write an midx when there is no objects, and another to check that `git multi-pack-index verify` warns when it verifies an midx with no objects. For this last test, use t5319/no-objects.midx which was generated by an older version of git. Signed-off-by: Damien Robert <damien.olivier.robert+git@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-21Merge branch 'en/rebase-backend'Libravatar Junio C Hamano1-1/+1
Test fix. * en/rebase-backend: t3419: prevent failure when run with EXPENSIVE
2020-03-20t3419: prevent failure when run with EXPENSIVELibravatar brian m. carlson1-1/+1
This test runs a function which itself runs several assertions. The last of these assertions cleans up the .git/rebase-apply directory, since when run with EXPENSIVE set, the function is invoked a second time to run the same tests with a larger data set. However, as of 2ac0d6273f ("rebase: change the default backend from "am" to "merge"", 2020-02-15), the default backend of rebase has changed, and cleaning up the rebase-apply directory has no effect: it no longer exists, since we're using rebase-merge instead. Since we don't really care which rebase backend is in use, let's just use the command "git rebase --quit", which will do the right thing regardless. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-16Merge branch 'en/test-cleanup'Libravatar Junio C Hamano2-23/+17
Test fixes. * en/test-cleanup: t6022, t6046: fix flaky files-are-updated checks
2020-03-16Merge branch 'es/outside-repo-errmsg-hints'Libravatar Junio C Hamano1-0/+38
An earlier update to show the location of working tree in the error message did not consider the possibility that a git command may be run in a bare repository, which has been corrected. * es/outside-repo-errmsg-hints: prefix_path: show gitdir if worktree unavailable
2020-03-15prefix_path: show gitdir if worktree unavailableLibravatar Emily Shaffer1-0/+38
If there is no worktree at present, we can still hint the user about Git's current directory by showing them the absolute path to the Git directory. Even though the Git directory doesn't make it as easy to locate the worktree in question, it can still help a user figure out what's going on while developing a script. This fixes a segmentation fault introduced in e0020b2f ("prefix_path: show gitdir when arg is outside repo", 2020-02-14). Signed-off-by: Emily Shaffer <emilyshaffer@google.com> [jc: added minimum tests, with help from Szeder Gábor] Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-13t6022, t6046: fix flaky files-are-updated checksLibravatar Elijah Newren2-23/+17
Several tests wanted to verify that files were actually modified by a merge, which it would do by checking that the mtime was updated. In order to avoid problems with the merge completing so fast that the mtime at the beginning and end of the operation was the same, these tests would first set the mtime of a file to something "old". This "old" value was usually determined as current system clock minus one second, truncated to the nearest integer. Unfortunately, it appears the system clock and filesystem clock are different and comparing across the two runs into race problems resulting in flaky tests. From https://stackoverflow.com/questions/14392975/timestamp-accuracy-on-ext4-sub-millsecond: date will call the gettimeofday system call which will always return the most accurate time available based on the cached kernel time, adjusted by the CPU cycle time if available to give nanosecond resolution. The timestamps stored in the file system however, are only based on the cached kernel time. ie The time calculated at the last timer interrupt. and from https://apenwarr.ca/log/20181113: Does mtime get set to >= the current time? No, this depends on clock granularity. For example, gettimeofday() can return times in microseconds on my system, but ext4 rounds timestamps down to the previous ~10ms (but not exactly 10ms) increment, with the surprising result that a newly-created file is almost always created in the past: $ python -c " import os, time t0 = time.time() open('testfile', 'w').close() print os.stat('testfile').st_mtime - t0 " -0.00234484672546 So, instead of trying to compare across what are effectively two different clocks, just avoid using the system clock. Any new updates to files have to give an mtime at least as big as what is already in the file, so we could define "old" as one second before the mtime found in the file before the merge starts. But, to avoid problems with leap seconds, ntp updates, filesystems that only provide two second resolution, and other such weirdness, let's just pick an hour before the mtime found in the file before the merge starts. Also, clarify in one test where we check the mtime of different files that it really was intentional. I totally forgot the reasons for that and assumed it was a bug when asked. Reported-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-12Merge branch 'en/rebase-backend'Libravatar Junio C Hamano1-0/+8
Band-aid fixes for two fallouts from switching the default "rebase" backend. * en/rebase-backend: git-rebase.txt: highlight backend differences with commit rewording sequencer: clear state upon dropping a become-empty commit i18n: unmark a message in rebase.c
2020-03-11sequencer: clear state upon dropping a become-empty commitLibravatar Elijah Newren1-0/+8
In commit e98c4269c8 ("rebase (interactive-backend): fix handling of commits that become empty", 2020-02-15), the merge backend was changed to drop commits that did not start empty but became so after being applied (because their changes were a subset of what was already upstream). This new code path did not need to go through the process of creating a commit, since we were dropping the commit instead. Unfortunately, this also means we bypassed the clearing of the CHERRY_PICK_HEAD and MERGE_MSG files, which if there were no further commits to cherry-pick would mean that the rebase would end but assume there was still an operation in progress. Ensure that we clear such state files when we decide to drop the commit. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-11Merge branch 'ds/sparse-add'Libravatar Junio C Hamano1-1/+1
Test fix. * ds/sparse-add: t1091: don't grep for `strerror()` string
2020-03-09Merge branch 'hd/show-one-mergetag-fix'Libravatar Junio C Hamano1-0/+20
"git show" and others gave an object name in raw format in its error output, which has been corrected to give it in hex. * hd/show-one-mergetag-fix: show_one_mergetag: print non-parent in hex form.
2020-03-09Merge branch 'en/test-cleanup'Libravatar Junio C Hamano9-677/+752
Test cleanup. * en/test-cleanup: t6020: new test with interleaved lexicographic ordering of directories t6022, t6046: test expected behavior instead of testing a proxy for it t3035: prefer test_must_fail to bash negation for git commands t6020, t6022, t6035: update merge tests to use test helper functions t602[1236], t6034: modernize test formatting
2020-03-09Merge branch 'en/merge-path-collision'Libravatar Junio C Hamano1-9/+30
Handling of conflicting renames in merge-recursive have further been made consistent with how existing codepaths try to mimic what is done to add/add conflicts. * en/merge-path-collision: merge-recursive: apply collision handling unification to recursive case
2020-03-09Merge branch 'rj/t1050-use-test-path-is-file'Libravatar Junio C Hamano1-4/+6
Code cleanup. * rj/t1050-use-test-path-is-file: t1050: replace test -f with test_path_is_file
2020-03-09Merge branch 'pb/am-show-current-patch'Libravatar Junio C Hamano3-0/+40
"git am --short-current-patch" is a way to show the piece of e-mail for the stopped step, which is not suitable to directly feed "git apply" (it is designed to be a good "git am" input). It learned a new option to show only the patch part. * pb/am-show-current-patch: am: support --show-current-patch=diff to retrieve .git/rebase-apply/patch am: support --show-current-patch=raw as a synonym for--show-current-patch am: convert "resume" variable to a struct parse-options: convert "command mode" to a flag parse-options: add testcases for OPT_CMDMODE()
2020-03-09Merge branch 'am/pathspec-f-f-more'Libravatar Junio C Hamano3-0/+184
"git rm" and "git stash" learns the new "--pathspec-from-file" option. * am/pathspec-f-f-more: stash push: support the --pathspec-from-file option stash: eliminate crude option parsing doc: stash: synchronize <pathspec> description doc: stash: document more options doc: stash: split options from description (2) doc: stash: split options from description (1) rm: support the --pathspec-from-file option doc: rm: synchronize <pathspec> description
2020-03-09t1091: don't grep for `strerror()` stringLibravatar Martin Ågren1-1/+1
We grep for "File exists" in stderr of the failing `git sparse-checkout` to make sure that it failed for the right reason. We expect the string to show up there since we call `strerror(errno)` in `unable_to_lock_message()` in lockfile.c. On the NonStop platform, this fails because the error string is "File already exists", which doesn't match our grepping. See 9042140097 ("test-dir-iterator: do not assume errno values", 2019-07-30) for a somewhat similar fix. There, we patched a test helper, which meant we had access to `errno` and could investigate it better in the test helper instead of just outputting the numerical value and evaluating it in the test script. The current situation is different, since (short of modifying the lockfile machinery, e.g., to be more verbose) we don't have more than the output from `strerror()` available. Except we do: We prefix `strerror(errno)` with `_("Unable to create '%s.lock': ")`. Let's grep for that part instead. It verifies that we were indeed unable to create the lock file. (If that fails for some other reason than the file existing, we really really should expect other tests to fail as well.) An alternative fix would be to loosen the expression a bit and grep for "File.* exists" instead. There would be no guarantee that some other implementation couldn't come up with another error string, That is, that could be the first move in an endless game of whack-a-mole. Of course, it could also take us from "99" to "100" percent of the platforms and we'd never have this problem again. But since we have another way of addressing this, let's not even try the "loosen it up a bit" strategy. Reported-by: Randall S. Becker <rsbecker@nexbridge.com> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Acked-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-05t5537: adjust test_oid labelLibravatar Johannes Schindelin1-3/+3
We recently switched to using Perl instead of `sed` in the httpd-based tests. Let's reflect that in the label we give the corresponding commit hashes. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-05Merge branch 'js/ci-windows-update'Libravatar Junio C Hamano8-59/+66
Updates to the CI settings. * js/ci-windows-update: Azure Pipeline: switch to the latest agent pools ci: prevent `perforce` from being quarantined t/lib-httpd: avoid using macOS' sed
2020-03-05Merge branch 'be/describe-multiroot'Libravatar Junio C Hamano1-0/+51
"git describe" in a repository with multiple root commits sometimes gave up looking for the best tag to describe a given commit with too early, which has been adjusted. * be/describe-multiroot: describe: don't abort too early when searching tags
2020-03-05Merge branch 'es/recursive-single-branch-clone'Libravatar Junio C Hamano1-1/+12
"git clone --recurse-submodules --single-branch" now uses the same single-branch option when cloning the submodules. * es/recursive-single-branch-clone: clone: pass --single-branch during --recurse-submodules submodule--helper: use C99 named initializer
2020-03-05Merge branch 'es/do-not-let-rebase-switch-to-protected-branch'Libravatar Junio C Hamano1-1/+19
"git rebase BASE BRANCH" rebased/updated the tip of BRANCH and checked it out, even when the BRANCH is checked out in a different worktree. This has been corrected. * es/do-not-let-rebase-switch-to-protected-branch: rebase: refuse to switch to branch already checked out elsewhere t3400: make test clean up after itself
2020-03-05Merge branch 'hv/receive-denycurrent-everywhere'Libravatar Junio C Hamano3-1/+29
"git push" should stop from updating a branch that is checked out when receive.denyCurrentBranch configuration is set, but it failed to pay attention to checkouts in secondary worktrees. This has been corrected. * hv/receive-denycurrent-everywhere: t2402: test worktree path when called in .git directory receive.denyCurrentBranch: respect all worktrees t5509: use a bare repository for test push target get_main_worktree(): allow it to be called in the Git directory
2020-03-05Merge branch 'es/worktree-avoid-duplication-fix'Libravatar Junio C Hamano1-0/+9
In rare cases "git worktree add <path>" could think that <path> was already a registered worktree even when it wasn't and refuse to add the new worktree. This has been corrected. * es/worktree-avoid-duplication-fix: worktree: don't allow "add" validation to be fooled by suffix matching worktree: add utility to find worktree by pathname worktree: improve find_worktree() documentation
2020-03-05Merge branch 'bc/wildcard-credential'Libravatar Junio C Hamano2-0/+134
A configuration element used for credential subsystem can now use wildcard pattern to specify for which set of URLs the entry applies. * bc/wildcard-credential: credential: allow wildcard patterns when matching config credential: use the last matching username in the config t0300: add tests for some additional cases t1300: add test for urlmatch with multiple wildcards mailmap: add an additional email address for brian m. carlson
2020-03-05Merge branch 'ds/sparse-add'Libravatar Junio C Hamano1-1/+84
"git sparse-checkout" learned a new "add" subcommand. * ds/sparse-add: sparse-checkout: allow one-character directories in cone mode sparse-checkout: work with Windows paths sparse-checkout: create 'add' subcommand sparse-checkout: extract pattern update from 'set' subcommand sparse-checkout: extract add_patterns_from_input()
2020-03-04t2402: test worktree path when called in .git directoryLibravatar Hariom Verma1-0/+6
The bug which reports an extra `/.git/.` in worktree path when called in '.git' directory already has been fixed. But unfortunately, the regression test to ensure this behavior has been forgotten. Here is that test. Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Hariom Verma <hariom18599@gmail.com> Acked-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-02Merge branch 'ma/test-cleanup'Libravatar Junio C Hamano13-17/+5
Code cleanup. * ma/test-cleanup: t: drop debug `cat` calls t9810: drop debug `cat` call t4117: check for files using `test_path_is_file`
2020-03-02Merge branch 'rs/micro-cleanups'Libravatar Junio C Hamano1-1/+1
Code cleanup. * rs/micro-cleanups: use strpbrk(3) to search for characters from a given set quote: use isalnum() to check for alphanumeric characters
2020-03-02Merge branch 'ak/test-log-graph'Libravatar Junio C Hamano5-107/+74
Test update. * ak/test-log-graph: lib-log-graph: consolidate colored graph cmp logic lib-log-graph: consolidate test_cmp_graph logic
2020-03-02Merge branch 'ds/partial-clone-fixes'Libravatar Junio C Hamano1-0/+31
Fix for a bug revealed by a recent change to make the protocol v2 the default. * ds/partial-clone-fixes: partial-clone: avoid fetching when looking for objects partial-clone: demonstrate bugs in partial fetch
2020-03-02Merge branch 'en/t3433-rebase-stat-dirty-failure'Libravatar Junio C Hamano1-0/+48
The merge-recursive machinery failed to refresh the cache entry for a merge result in a couple of places, resulting in an unnecessary merge failure, which has been fixed. * en/t3433-rebase-stat-dirty-failure: merge-recursive: fix the refresh logic in update_file_flags t3433: new rebase testcase documenting a stat-dirty-like failure
2020-03-02Merge branch 'en/rebase-backend'Libravatar Junio C Hamano17-133/+304
"git rebase" has learned to use the merge backend (i.e. the machinery that drives "rebase -i") by default, while allowing "--apply" option to use the "apply" backend (e.g. the moral equivalent of "format-patch piped to am"). The rebase.backend configuration variable can be set to customize. * en/rebase-backend: rebase: rename the two primary rebase backends rebase: change the default backend from "am" to "merge" rebase: make the backend configurable via config setting rebase tests: repeat some tests using the merge backend instead of am rebase tests: mark tests specific to the am-backend with --am rebase: drop '-i' from the reflog for interactive-based rebases git-prompt: change the prompt for interactive-based rebases rebase: add an --am option rebase: move incompatibility checks between backend options a bit earlier git-rebase.txt: add more details about behavioral differences of backends rebase: allow more types of rebases to fast-forward t3432: make these tests work with either am or merge backends rebase: fix handling of restrict_revision rebase: make sure to pass along the quiet flag to the sequencer rebase, sequencer: remove the broken GIT_QUIET handling t3406: simplify an already simple test rebase (interactive-backend): fix handling of commits that become empty rebase (interactive-backend): make --keep-empty the default t3404: directly test the behavior of interest git-rebase.txt: update description of --allow-empty-message
2020-03-02Merge branch 'en/check-ignore'Libravatar Junio C Hamano1-16/+23
"git check-ignore" did not work when the given path is explicitly marked as not ignored with a negative entry in the .gitignore file. * en/check-ignore: check-ignore: fix documentation and implementation to match
2020-03-02Merge branch 'jk/object-filter-with-bitmap'Libravatar Junio C Hamano5-7/+146
The object reachability bitmap machinery and the partial cloning machinery were not prepared to work well together, because some object-filtering criteria that partial clones use inherently rely on object traversal, but the bitmap machinery is an optimization to bypass that object traversal. There however are some cases where they can work together, and they were taught about them. * jk/object-filter-with-bitmap: rev-list --count: comment on the use of count_right++ pack-objects: support filters with bitmaps pack-bitmap: implement BLOB_LIMIT filtering pack-bitmap: implement BLOB_NONE filtering bitmap: add bitmap_unset() function rev-list: use bitmap filters for traversal pack-bitmap: basic noop bitmap filter infrastructure rev-list: allow commit-only bitmap traversals t5310: factor out bitmap traversal comparison rev-list: allow bitmaps when counting objects rev-list: make --count work with --objects rev-list: factor out bitmap-optimized routines pack-bitmap: refuse to do a bitmap traversal with pathspecs rev-list: fallback to non-bitmap traversal when filtering pack-bitmap: fix leak of haves/wants object lists pack-bitmap: factor out type iterator initialization
2020-03-02show_one_mergetag: print non-parent in hex form.Libravatar Harald van Dijk1-0/+20
When a mergetag names a non-parent, which can occur after a shallow clone, its hash was previously printed as raw data. Print it in hex form instead. Signed-off-by: Harald van Dijk <harald@gigawatt.nl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-27t6020: new test with interleaved lexicographic ordering of directoriesLibravatar Elijah Newren1-0/+43
If a repository has two files: foo/bar/baz foo/bar-2/baz then a simple lexicographic ordering of files and directories shows ... foo/bar foo/bar-2 foo/bar/baz ... and the appearance of foo/bar-2 between foo/bar and foo/bar/baz can trip up some codepaths. Add a test to catch such cases. t6020 might be a slight misfit since this testcase does not test any kind of file/directory conflict. However, it is similar in spirit to some tests (4-6) already in t6020 that check cases where a *file* sorted between a directory and the files underneath that directory. This testcase differs in that now there is a *directory* that sorts in the middle. Although merge-recursive currently has no problems with this simple testcase, I discovered that it's very possible to accidentally mess it up. Further, we have no other merge or cherry-pick or rebase testcases in the entire testsuite that cover such a case, so I felt like it would be a worthwhile addition to the testsuite. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-27t6022, t6046: test expected behavior instead of testing a proxy for itLibravatar Elijah Newren2-34/+70
In t6022, we were testing for file being overwritten (or not) based on an output message instead of checking for the file being overwritten. Since we can check for the file being overwritten via mtime updates, check that instead. In t6046, we were largely checking for both the expected behavior and a proxy for it, which is unnecessary. The calls to test-tool also were a bit cryptic. Make them a little clearer. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-27t3035: prefer test_must_fail to bash negation for git commandsLibravatar Elijah Newren1-2/+2
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-27t6020, t6022, t6035: update merge tests to use test helper functionsLibravatar Elijah Newren3-47/+47
Make use of test_path_is_file, test_write_lines, and similar helpers in these old test files. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-27t602[1236], t6034: modernize test formattingLibravatar Elijah Newren5-595/+591
Indent code, and include it inside test_expect* blocks. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-27merge-recursive: apply collision handling unification to recursive caseLibravatar Elijah Newren1-9/+30
In the en/merge-path-collision topic (see commit ac193e0e0aa5, "Merge branch 'en/merge-path-collision'", 2019-01-04), all the "file collision" conflict types were modified for consistency. In particular, rename/add, rename/rename(2to1) and each rename/add piece of a rename/rename(1to2)/add[/add] conflict were made to behave like add/add conflicts have always been handled. However, this consistency was not enforced when opt->priv->call_depth > 0 for rename/rename conflicts. Update rename/rename(1to2) and rename/rename(2to1) conflicts in the recursive case to also be consistent. As an added bonus, this simplifies the code considerably. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-27t/lib-httpd: avoid using macOS' sedLibravatar Johannes Schindelin8-59/+66
Among other differences relative to GNU sed, macOS' sed always ends its output with a trailing newline, even if the input did not have such a trailing newline. Surprisingly, this makes three httpd-based tests fail on macOS: t5616, t5702 and t5703. ("Surprisingly" because those tests have been around for some time, but apparently nobody runs them on macOS with a working Apache2 setup.) The reason is that we use `sed` in those tests to filter the response of the web server. Apart from the fact that we use GNU constructs (such as using a space after the `c` command instead of a backslash and a newline), we have another problem: macOS' sed LF-only newlines while webservers are supposed to use CR/LF ones. Even worse, t5616 uses `sed` to replace a binary part of the response with a new binary part (kind of hoping that the replaced binary part does not contain a 0x0a byte which would be interpreted as a newline). To that end, it calls on Perl to read the binary pack file and hex-encode it, then calls on `sed` to prefix every hex digit pair with a `\x` in order to construct the text that the `c` statement of the `sed` invocation is supposed to insert. So we call Perl and sed to construct a sed statement. The final nail in the coffin is that macOS' sed does not even interpret those `\x<hex>` constructs. Let's just replace all of that by Perl snippets. With Perl, at least, we do not have to deal with GNU vs macOS semantics, we do not have to worry about unwanted trailing newlines, and we do not have to spawn commands to construct arguments for other commands to be spawned (i.e. we can avoid a whole lot of shell scripting complexity). The upshot is that this fixes t5616, t5702 and t5703 on macOS with Apache2. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-26describe: don't abort too early when searching tagsLibravatar Benno Evers1-0/+51
When searching the commit graph for tag candidates, `git-describe` will stop as soon as there is only one active branch left and it already found an annotated tag as a candidate. This works well as long as all branches eventually connect back to a common root, but if the tags are found across branches with no common ancestor B o----. \ o-----o---o----x A it can happen that the search on one branch terminates prematurely because a tag was found on another, independent branch. This scenario isn't quite as obscure as it sounds, since cloning with a limited depth often introduces many independent "dead ends" into the commit graph. The help text of `git-describe` states pretty clearly that when describing a commit D, the number appended to the emitted tag X should correspond to the number of commits found by `git log X..D`. Thus, this commit modifies the stopping condition to only abort the search when only one branch is left to search *and* all current best candidates are descendants from that branch. For repositories with a single root, this condition is always true: When the search is reduced to a single active branch, the current commit must be an ancestor of *all* tag candidates. This means that in the common case, this change will have no negative performance impact since the same number of commits as before will be traversed. Signed-off-by: Benno Evers <benno@bmevers.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-25Merge branch 'es/bright-colors'Libravatar Junio C Hamano1-0/+12
The basic 7 colors learned the brighter counterparts (e.g. "brightred"). * es/bright-colors: color.c: alias RGB colors 8-15 to aixterm colors color.c: support bright aixterm colors color.c: refactor color_output arguments
2020-02-25Merge branch 'bw/remote-rename-update-config'Libravatar Junio C Hamano3-3/+100
"git remote rename X Y" needs to adjust configuration variables (e.g. branch.<name>.remote) whose value used to be X to Y. branch.<name>.pushRemote is now also updated. * bw/remote-rename-update-config: remote rename/remove: gently handle remote.pushDefault config config: provide access to the current line number remote rename/remove: handle branch.<name>.pushRemote config values remote: clean-up config callback remote: clean-up by returning early to avoid one indentation pull --rebase/remote rename: document and honor single-letter abbreviations rebase types
2020-02-25clone: pass --single-branch during --recurse-submodulesLibravatar Emily Shaffer1-1/+12
Previously, performing "git clone --recurse-submodules --single-branch" resulted in submodules cloning all branches even though the superproject cloned only one branch. Pipe --single-branch through the submodule helper framework to make it to 'clone' later on. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-24lib-log-graph: consolidate colored graph cmp logicLibravatar Abhishek Kumar4-30/+20
Signed-off-by: Abhishek Kumar <abhishekkumar8222@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-24lib-log-graph: consolidate test_cmp_graph logicLibravatar Abhishek Kumar5-77/+54
Log graph comparision logic is duplicated many times in: - t3430-rebase-merges.sh - t4202-log.sh - t4214-log-graph-octopus.sh - t4215-log-skewed-merges.sh Consolidate the core of the comparision and sanitization logic in lib-log-graph, and use it to replace the existing tests. While at it, lose the singular/plural transition magic from the sanitize_output helper, which was necessary around 7f814632 ("Use correct grammar in diffstat summary line", 2012-02-01), that has long outlived its usefulness. Signed-off-by: Abhishek Kumar <abhishekkumar8222@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-02-24worktree: don't allow "add" validation to be fooled by suffix matchingLibravatar Eric Sunshine1-0/+9
"git worktree add <path>" performs various checks before approving <path> as a valid location for the new worktree. Aside from ensuring that <path> does not already exist, one of the questions it asks is whether <path> is already a registered worktree. To perform this check, it queries find_worktree() and disallows the "add" operation if find_worktree() finds a match for <path>. As a convenience, however, find_worktree() casts an overly wide net to allow users to identify worktrees by shorthand in order to keep typing to a minimum. For instance, it performs suffix matching which, given subtrees "foo/bar" and "foo/baz", can correctly select the latter when asked only for "baz". "add" validation knows the exact path it is interrogating, so this sort of heuristic-based matching is, at best, questionable for this use-case and, at worst, may may accidentally interpret <path> as matching an existing worktree and incorrectly report it as already registered even when it isn't. (In fact, validate_worktree_add() already contains a special case to avoid accidentally matching against the main worktree, precisely due to this problem.) Avoid the problem of potential accidental matching against an existing worktree by instead taking advantage of find_worktree_by_path() which matches paths deterministically, without applying any sort of magic shorthand matching performed by find_worktree(). Reported-by: Cameron Gunnin <cameron.gunnin@synopsys.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>