summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2020-10-29Merge branch 'jk/committer-date-is-author-date-fix' into maintLibravatar Junio C Hamano1-2/+2
In 2.29, "--committer-date-is-author-date" option of "rebase" and "am" subcommands lost the e-mail address by mistake, which has been corrected. * jk/committer-date-is-author-date-fix: rebase: fix broken email with --committer-date-is-author-date am: fix broken email with --committer-date-is-author-date t3436: check --committer-date-is-author-date result more carefully
2020-10-23rebase: fix broken email with --committer-date-is-author-dateLibravatar Jeff King1-4/+4
Commit 7573cec52c (rebase -i: support --committer-date-is-author-date, 2020-08-17) copied the committer ident-parsing code from builtin/am.c. And in doing so, it copied a bug in which we always set the email to an empty string. We fixed the version in git-am in the previous commit; this commit fixes the copied code. Reported-by: VenomVendor <info@venomvendor.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-23am: fix broken email with --committer-date-is-author-dateLibravatar Jeff King1-1/+1
Commit e8cbe2118a (am: stop exporting GIT_COMMITTER_DATE, 2020-08-17) rewrote the code for setting the committer date to use fmt_ident(), rather than setting an environment variable and letting commit_tree() handle it. But it introduced two bugs: - we use the author email string instead of the committer email - when parsing the committer ident, we used the wrong variable to compute the length of the email, resulting in it always being a zero-length string This commit fixes both, which causes our test of this option via the rebase "apply" backend to now succeed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-23t3436: check --committer-date-is-author-date result more carefullyLibravatar Jeff King1-7/+7
After running "rebase --committer-date-is-author-date", we confirm that the committer date is the same as the author date. However, we don't look at any other parts of the committer ident line to make sure we didn't screw them up. And indeed, there are a few bugs here. Depending on the rebase backend in use, we may accidentally use the author email instead of the committer's, or even an empty string. Let's teach our test_ctime_is_atime helper to check the committer name and email, which reveals several failing tests. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08Merge branch 'js/default-branch-name-part-3'Libravatar Junio C Hamano5-25/+25
Test preparation for the switch of default branch name continues. * js/default-branch-name-part-3: tests: avoid using the branch name `main` t1415: avoid using `main` as ref name
2020-10-08Merge branch 'jk/index-pack-hotfixes'Libravatar Junio C Hamano1-0/+7
Hotfix and clean-up for the jt/threaded-index-pack topic that has graduated to v2.29-rc0. * jk/index-pack-hotfixes: index-pack: make get_base_data() comment clearer index-pack: drop type_cas mutex index-pack: restore "resolving deltas" progress meter
2020-10-08Merge branch 'hx/push-atomic-with-cert'Libravatar Junio C Hamano1-4/+3
Hotfix to a recently added test script. * hx/push-atomic-with-cert: t5534: split stdout and stderr redirection
2020-10-08tests: avoid using the branch name `main`Libravatar Johannes Schindelin4-16/+16
In the near future, we want to change Git's default branch name to `main`. In preparation for that, stop using it as a branch name in the test suite. Replace that branch name by `topic`, the same name we used to rename variations of `master` in b6211b89eb3 (tests: avoid variations of the `master` branch name, 2020-09-26). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-08t1415: avoid using `main` as ref nameLibravatar Johannes Schindelin1-9/+9
In preparation for a patch series that will change the fall-back for `init.defaultBranch` to `main`, let's not use `main` as ref name in this test script. Otherwise, the `git for-each-ref ... | grep main` which wants to catch those refs would also unexpectedly catch `refs/heads/main`. Since the refs in question are worktree-local ones (i.e. each worktree has their own, just like `HEAD`), and since the test case already uses a secondary worktree called "second", let's use the name "first" for those refs instead. While at it, adjust the test titles that talk about a "repo" when they meant a "worktree" instead. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-07index-pack: restore "resolving deltas" progress meterLibravatar Jeff King1-0/+7
Commit f08cbf60fe (index-pack: make quantum of work smaller, 2020-09-08) refactored the main loop in threaded_second_pass(), but also deleted the call to display_progress() at the top of the loop. This means that users typically see no progress at all during the delta resolution phase (and for large repositories, Git appears to hang). This looks like an accident that was unrelated to the intended change of that commit, since we continue to update nr_resolved_deltas in resolve_delta(). Let's restore the call to get that progress back. We'll also add a test that confirms we generate the expected progress. This isn't perfect, as it wouldn't catch a bug where progress was delayed to the end. That was probably possible to trigger when receiving a thin pack, because we'd eventually call display_progress() from fix_unresolved_deltas(), but only once after doing all the work. However, since our test case generates a complete pack, it reliably demonstrates this particular bug and its fix. And we can't do better without making the test racy. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-06t5534: split stdout and stderr redirectionLibravatar Đoàn Trần Công Danh1-4/+3
On atomic pushing failure with GnuPG, we expect a very specific output in stdout due to `--porcelain` switch. On such failure, we also write down some helpful hint into stderr in order to help user understand what happens and how to continue from those failures. On a lot of system, those hint (in stderr) will be flushed first, then those messages in stdout will be flushed. In such systems, the current test code is fine as is. However, we don't have such guarantee, (at least) there're some real systems that writes those stream interleaved. On such systems, we may see the stderr stream written in the middle of stdout stream. Let's split those stream redirection. By splitting those stream, the output stream will contain exactly what we want to compare, thus, saving us a "sed" invocation. While we're at it, change the `test_i18ncmp` to `test_cmp` because we will never translate those messages (because of `--porcelain`). Signed-off-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-05Merge branch 'jk/format-auto-base-when-able'Libravatar Junio C Hamano1-0/+22
"git format-patch" learns to take "whenAble" as a possible value for the format.useAutoBase configuration variable to become no-op when the automatically computed base does not make sense. * jk/format-auto-base-when-able: format-patch: teach format.useAutoBase "whenAble" option
2020-10-05Merge branch 'jk/diff-cc-oidfind-fix'Libravatar Junio C Hamano1-0/+55
"log -c --find-object=X" did not work well to find a merge that involves a change to an object X from only one parent. * jk/diff-cc-oidfind-fix: combine-diff: handle --find-object in multitree code path
2020-10-05Merge branch 'jk/refspecs-negative'Libravatar Junio C Hamano1-0/+189
"git fetch" and "git push" support negative refspecs. * jk/refspecs-negative: refspec: add support for negative refspecs
2020-10-05Merge branch 'rs/archive-add-file'Libravatar Junio C Hamano2-0/+57
"git archive" learns the "--add-file" option to include untracked files into a snapshot from a tree-ish. * rs/archive-add-file: Makefile: use git-archive --add-file archive: add --add-file archive: read short blobs in archive.c::write_archive_entry()
2020-10-05Merge branch 'jt/keep-partial-clone-filter-upon-lazy-fetch'Libravatar Junio C Hamano1-1/+2
The lazy fetching done internally to make missing objects available in a partial clone incorrectly made permanent damage to the partial clone filter in the repository, which has been corrected. * jt/keep-partial-clone-filter-upon-lazy-fetch: fetch: do not override partial clone filter promisor-remote: remove unused variable
2020-10-05Merge branch 'td/submodule-update-quiet'Libravatar Junio C Hamano1-0/+12
"git submodule update --quiet" did not squelch underlying "rebase" and "pull" commands. * td/submodule-update-quiet: submodule update: silence underlying merge/rebase with "--quiet"
2020-10-05Merge branch 'jk/unused'Libravatar Junio C Hamano2-5/+5
Code cleanup. * jk/unused: dir.c: drop unused "untracked" from treat_path_fast() sequencer: handle ignore_footer when parsing trailers test-advise: check argument count with argc instead of argv sparse-checkout: fill in some options boilerplate sequencer: drop repository argument from run_git_commit() push: drop unused repo argument to do_push() assert PARSE_OPT_NONEG in parse-options callbacks env--helper: write to opt->value in parseopt helper drop unused argc parameters convert: drop unused crlf_action from check_global_conv_flags_eol()
2020-10-05Merge branch 'js/default-branch-name-part-2'Libravatar Junio C Hamano10-96/+96
Update the tests to drop word 'master' from them. * js/default-branch-name-part-2: t9902: avoid using the branch name `master` tests: avoid variations of the `master` branch name t3200: avoid variations of the `master` branch name fast-export: avoid using unnecessary language in a code comment t/test-terminal: avoid non-inclusive language
2020-10-05Merge branch 'ds/in-merge-bases-many-optim-bug'Libravatar Junio C Hamano2-0/+32
in_merge_bases_many(), a way to see if a commit is reachable from any commit in a set of commits, was totally broken when the commit-graph feature was in use, which has been corrected. * ds/in-merge-bases-many-optim-bug: commit-reach: fix in_merge_bases_many bug
2020-10-04Merge branch 'jk/shortlog-group-by-trailer'Libravatar Junio C Hamano1-0/+141
"git shortlog" has been taught to group commits by the contents of the trailer lines, like "Reviewed-by:", "Coauthored-by:", etc. * jk/shortlog-group-by-trailer: shortlog: allow multiple groups to be specified shortlog: parse trailer idents shortlog: rename parse_stdin_ident() shortlog: de-duplicate trailer values shortlog: match commit trailers with --group trailer: add interface for iterating over commit trailers shortlog: add grouping option shortlog: change "author" variables to "ident"
2020-10-04Merge branch 'cc/bisect-start-fix'Libravatar Junio C Hamano1-0/+7
"git bisect start X Y", when X and Y are not valid committish object names, should take X and Y as pathspec, but didn't. * cc/bisect-start-fix: bisect: don't use invalid oid as rev when starting
2020-10-04Merge branch 'jc/blame-ignore-fix'Libravatar Junio C Hamano1-22/+39
"git blame --ignore-rev/--ignore-revs-file" failed to validate their input are valid revision, and failed to take into account that the user may want to give an annotated tag instead of a commit, which has been corrected. * jc/blame-ignore-fix: blame: validate and peel the object names on the ignore list t8013: minimum preparatory clean-up
2020-10-02commit-reach: fix in_merge_bases_many bugLibravatar Derrick Stolee2-0/+32
Way back in f9b8908b (commit.c: use generation numbers for in_merge_bases(), 2018-05-01), a heuristic was used to short-circuit the in_merge_bases() walk. This works just fine as long as the caller is checking only two commits, but when there are multiple, there is a possibility that this heuristic is _very wrong_. Some code moves since then has changed this method to repo_in_merge_bases_many() inside commit-reach.c. The heuristic computes the minimum generation number of the "reference" list, then compares this number to the generation number of the "commit". In a recent topic, a test was added that used in_merge_bases_many() to test if a commit was reachable from a number of commits pulled from a reflog. However, this highlighted the problem: if any of the reference commits have a smaller generation number than the given commit, then the walk is skipped _even if there exist some with higher generation number_. This heuristic is wrong! It must check the MAXIMUM generation number of the reference commits, not the MINIMUM. This highlights a testing gap. t6600-test-reach.sh covers many methods in commit-reach.c, including in_merge_bases() and get_merge_bases_many(), but since these methods either restrict to two input commits or actually look for the full list of merge bases, they don't check this heuristic! Add a possible input to "test-tool reach" that tests in_merge_bases_many() and add tests to t6600-test-reach.sh that cover this heuristic. This includes cases for the reference commits having generation above and below the generation of the input commit, but also having maximum generation below the generation of the input commit. The fix itself is to swap min_generation with a max_generation in repo_in_merge_bases_many(). Reported-by: Srinidhi Kaushik <shrinidhi.kaushik@gmail.com> Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-01format-patch: teach format.useAutoBase "whenAble" optionLibravatar Jacob Keller1-0/+22
The format.useAutoBase configuration option exists to allow users to enable '--base=auto' for format-patch by default. This can sometimes lead to poor workflow, due to unexpected failures when attempting to format an ancient patch: $ git format-patch -1 <an old commit> fatal: base commit shouldn't be in revision list This can be very confusing, as it is not necessarily immediately obvious that the user requested a --base (since this was in the configuration, not on the command line). We do want --base=auto to fail when it cannot provide a suitable base, as it would be equally confusing if a formatted patch did not include the base information when it was requested. Teach format.useAutoBase a new mode, "whenAble". This mode will cause format-patch to attempt to include a base commit when it can. However, if no valid base commit can be found, then format-patch will continue formatting the patch without a base commit. In order to avoid making yet another branch name unusable with --base, do not teach --base=whenAble or --base=whenable. Instead, refactor the base_commit option to use a callback, and rely on the global configuration variable auto_base. This does mean that a user cannot request this optional base commit generation from the command line. However, this is likely not too valuable. If the user requests base information manually, they will be immediately informed of the failure to acquire a suitable base commit. This allows the user to make an informed choice about whether to continue the format. Add tests to cover the new mode of operation for --base. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-10-01submodule update: silence underlying merge/rebase with "--quiet"Libravatar Theodore Dubois1-0/+12
Commands such as $ git pull --rebase --recurse-submodules --quiet produce non-quiet output from the merge or rebase. Pass the --quiet option down when invoking "rebase" and "merge". Also fix the parsing of git submodule update -v. When e84c3cf3 (git-submodule.sh: accept verbose flag in cmd_update to be non-quiet, 2018-08-14) taught "git submodule update" to take "--quiet", it apparently did not know how ${GIT_QUIET:+--quiet} works, and reviewers seem to have missed that setting the variable to "0", rather than unsetting it, still results in "--quiet" being passed to underlying commands. Signed-off-by: Theodore Dubois <tbodt@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30refspec: add support for negative refspecsLibravatar Jacob Keller1-0/+189
Both fetch and push support pattern refspecs which allow fetching or pushing references that match a specific pattern. Because these patterns are globs, they have somewhat limited ability to express more complex situations. For example, suppose you wish to fetch all branches from a remote except for a specific one. To allow this, you must setup a set of refspecs which match only the branches you want. Because refspecs are either explicit name matches, or simple globs, many patterns cannot be expressed. Add support for a new type of refspec, referred to as "negative" refspecs. These are prefixed with a '^' and mean "exclude any ref matching this refspec". They can only have one "side" which always refers to the source. During a fetch, this refers to the name of the ref on the remote. During a push, this refers to the name of the ref on the local side. With negative refspecs, users can express more complex patterns. For example: git fetch origin refs/heads/*:refs/remotes/origin/* ^refs/heads/dontwant will fetch all branches on origin into remotes/origin, but will exclude fetching the branch named dontwant. Refspecs today are commutative, meaning that order doesn't expressly matter. Rather than forcing an implied order, negative refspecs will always be applied last. That is, in order to match, a ref must match at least one positive refspec, and match none of the negative refspecs. This is similar to how negative pathspecs work. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30combine-diff: handle --find-object in multitree code pathLibravatar Jeff King1-0/+55
When doing combined diffs, we have two possible code paths: - a slower one which independently diffs against each parent, applies any filters, and then intersects the resulting paths - a faster one which walks all trees simultaneously When the diff options specify that we must do certain filters, like pickaxe, then we always use the slow path, since the pickaxe code only knows how to handle filepairs, not the n-parent entries generated for combined diffs. But there are two problems with the slow path: 1. It's slow. Running: git rev-list HEAD | git diff-tree --stdin -r -c in git.git takes ~3s on my machine. But adding "--find-object" to that increases it to ~6s, even though find-object itself should incur only a few extra oid comparisons. On linux.git, it's even worse: 35s versus 215s. 2. It doesn't catch all cases where a particular path is interesting. Consider a merge with parent blobs X and Y for a particular path, and end result Z. That should be interesting according to "-c", because the result doesn't match either parent. And it should be interesting even with "--find-object=X", because "X" went away in the merge. But because we perform each pairwise diff independently, this confuses the intersection code. The change from X to Z is still interesting according to --find-object. But in the other parent we went from Y to Z, so the diff appears empty! That causes the intersection code to think that parent didn't change the path, and thus it's not interesting for "-c". This patch fixes both by implementing --find-object for the multitree code. It's a bit unfortunate that we have to duplicate some logic from diffcore-pickaxe, but this is the best we can do for now. In an ideal world, all of the diffcore code would stop thinking about filepairs and start thinking about n-parent sets, and we could use the multitree walk with all of it. Until then, there are some leftover warts: - other pickaxe operations, like -S or -G, still suffer from both problems. These would be hard to adapt because they rely on having a diff_filespec() for each path to look at content. And we'd need to define what an n-way "change" means in each case (probably easy for "-S", which can compare counts, but not so clear for -G, which is about grepping diffs). - other options besides --find-object may cause us to use the slow pairwise path, in which case we'll go back to producing a different (wrong) answer for the X/Y/Z case above. We may be able to hack around these, but I think the ultimate solution will be a larger rewrite of the diffcore code. For now, this patch improves one specific case but leaves the rest. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30test-advise: check argument count with argc instead of argvLibravatar Jeff King1-2/+2
We complain if "test-tool advise" is not given an argument, but we quietly ignore any additional arguments it receives. Let's instead check that we got the expected number. As a bonus, this silences -Wunused-parameter, which notes that we don't ever look at argc. While we're here, we can also fix the indentation in the conditional. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-30drop unused argc parametersLibravatar Jeff King1-3/+3
Many functions take an argv/argc pair, but never actually look at argc. This makes it useless at best (we use the NULL sentinel in argv to find the end of the array), and misleading at worst (what happens if the argc count does not match the argv NULL?). In each of these instances, the argv NULL does match the argc count, so there are no bugs here. But let's tighten the interfaces to make it harder to get wrong (and to reduce some -Wunused-parameter complaints). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-29Merge branch 'ah/pull'Libravatar Junio C Hamano1-1/+20
Earlier we taught "git pull" to warn when the user does not say the histories need to be merged, rebased or accepts only fast- forwarding, but the warning triggered for those who have set the pull.ff configuration variable. * ah/pull: pull: don't warn if pull.ff has been set
2020-09-29Merge branch 'tg/range-diff-same-file-fix'Libravatar Junio C Hamano1-8/+4
"git range-diff" showed incorrect diffstat, which has been corrected. * tg/range-diff-same-file-fix: diff: fix modified lines stats with --stat and --numstat
2020-09-29Merge branch 'jc/t1506-rev-parse-leaves-range-endpoint-unpeeled'Libravatar Junio C Hamano1-0/+18
Test update. * jc/t1506-rev-parse-leaves-range-endpoint-unpeeled: t1506: rev-parse A..B and A...B
2020-09-29Merge branch 'bc/clone-with-git-default-hash-fix'Libravatar Junio C Hamano1-0/+14
"git clone" that clones from SHA-1 repository, while GIT_DEFAULT_HASH set to use SHA-256 already, resulted in an unusable repository that half-claims to be SHA-256 repository with SHA-1 objects and refs. This has been corrected. * bc/clone-with-git-default-hash-fix: builtin/clone: avoid failure with GIT_DEFAULT_HASH
2020-09-29Merge branch 'tb/bloom-improvements'Libravatar Junio C Hamano5-24/+246
"git commit-graph write" learned to limit the number of bloom filters that are computed from scratch with the --max-new-filters option. * tb/bloom-improvements: commit-graph: introduce 'commitGraph.maxNewFilters' builtin/commit-graph.c: introduce '--max-new-filters=<n>' commit-graph: rename 'split_commit_graph_opts' bloom: encode out-of-bounds filters as non-empty bloom/diff: properly short-circuit on max_changes bloom: use provided 'struct bloom_filter_settings' bloom: split 'get_bloom_filter()' in two commit-graph.c: store maximum changed paths commit-graph: respect 'commitGraph.readChangedPaths' t/helper/test-read-graph.c: prepare repo settings commit-graph: pass a 'struct repository *' in more places t4216: use an '&&'-chain commit-graph: introduce 'get_bloom_filter_settings()'
2020-09-28fetch: do not override partial clone filterLibravatar Jonathan Tan1-1/+2
When a fetch with the --filter argument is made, the configured default filter is set even if one already exists. This change was made in 5e46139376 ("builtin/fetch: remove unique promisor remote limitation", 2019-06-25) - in particular, changing from: * If this is the FIRST partial-fetch request, we enable partial * on this repo and remember the given filter-spec as the default * for subsequent fetches to this remote. to: * If this is a partial-fetch request, we enable partial on * this repo if not already enabled and remember the given * filter-spec as the default for subsequent fetches to this * remote. (The given filter-spec is "remembered" even if there is already an existing one.) This is problematic whenever a lazy fetch is made, because lazy fetches are made using "git fetch --filter=blob:none", but this will also happen if the user invokes "git fetch --filter=<filter>" manually. Therefore, restore the behavior prior to 5e46139376, which writes a filter-spec only if the current fetch request is the first partial-fetch one (for that remote). Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-27shortlog: allow multiple groups to be specifiedLibravatar Jeff King1-0/+74
Now that shortlog supports reading from trailers, it can be useful to combine counts from multiple trailers, or between trailers and authors. This can be done manually by post-processing the output from multiple runs, but it's non-trivial to make sure that each name/commit pair is counted only once. This patch teaches shortlog to accept multiple --group options on the command line, and pull data from all of them. That makes it possible to run: git shortlog -ns --group=author --group=trailer:co-authored-by to get a shortlog that counts authors and co-authors equally. The implementation is mostly straightforward. The "group" enum becomes a bitfield, and the trailer key becomes a list. I didn't bother implementing the multi-group semantics for reading from stdin. It would be possible to do, but the existing matching code makes it awkward, and I doubt anybody cares. The duplicate suppression we used for trailers now covers authors and committers as well (though in non-trailer single-group mode we can skip the hash insertion and lookup, since we only see one value per commit). There is one subtlety: we now care about the case when no group bit is set (in which case we default to showing the author). The caller in builtin/log.c needs to be adapted to ask explicitly for authors, rather than relying on shortlog_init(). It would be possible with some gymnastics to make this keep working as-is, but it's not worth it for a single caller. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-27shortlog: parse trailer identsLibravatar Jeff King1-0/+20
Trailers don't necessarily contain name/email identity values, so shortlog has so far treated them as opaque strings. However, since many trailers do contain identities, it's useful to treat them as such when they can be parsed. That lets "-e" work as usual, as well as mailmap. When they can't be parsed, we'll continue with the old behavior of treating them as a single string (there's no new test for that here, since the existing tests cover a trailer like this). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-27shortlog: de-duplicate trailer valuesLibravatar Jeff King1-0/+28
The current documentation is vague about what happens with --group=trailer:signed-off-by when we see a commit with: Signed-off-by: One Signed-off-by: Two Signed-off-by: One We clearly should credit both "One" and "Two", but should "One" get credited twice? The current code does so, but mostly because that was the easiest thing to do. It's probably more useful to count each commit at most once. This will become especially important when we allow values from multiple sources in a future patch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-27shortlog: match commit trailers with --groupLibravatar Jeff King1-0/+14
If a project uses commit trailers, this patch lets you use shortlog to see who is performing each action. For example, running: git shortlog -ns --group=trailer:reviewed-by in git.git shows who has reviewed. You can even use a custom format to see things like who has helped whom: git shortlog --format="...helped %an (%ad)" \ --group=trailer:helped-by Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-27shortlog: add grouping optionLibravatar Jeff King1-0/+5
In preparation for adding more grouping types, let's refactor the committer/author grouping code and add a user-facing option that binds them together. In particular: - the main option is now "--group", to make it clear that the various group types are mutually exclusive. The "--committer" option is an alias for "--group=committer". - we keep an enum rather than a binary flag, to prepare for more values - we prefer switch statements to ternary assignment, since other group types will need more custom code Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-26t9902: avoid using the branch name `master`Libravatar Johannes Schindelin1-5/+5
The completion tests used that name unnecessarily, and it is a non-inclusive term, so let's avoid using it here. Since three of the touched test cases make use of the fact that two of the branch names (`master` and `maint`) start with the same letter (or even with the same two letters), we choose to replace the use of `master` by a name that also has that property: `main`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-26tests: avoid variations of the `master` branch nameLibravatar Johannes Schindelin7-58/+58
The term `master` has a loaded history that serves as a constant reminder of racial injustice. The Git project has no desire to perpetuate this and already started avoiding it. The test suite uses variations of this name for branches other than the default one. Apart from t3200, where we just addressed this in the previous commit, those instances can be renamed in an automated manner because they do not require any changes outside of the test script, so let's do that. Seeing as the touched branches have very little (if anything) to do with the default branch, we choose to use a completely separate naming scheme: `topic_<number>` (it cannot be `topic-<number>` because t5515 uses the `test_oid` machinery with the term, and that machinery uses shell variables internally, whose names cannot contain dashes). This trick was performed by this (GNU) sed invocation: $ sed -i 's/master\([a-z0-9]\)/topic_\1/g' t/t*.sh Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-25Merge branch 'hx/push-atomic-with-cert'Libravatar Junio C Hamano1-0/+23
"git push" that wants to be atomic and wants to send push certificate learned not to prepare and sign the push certificate when it fails the local check (hence due to atomicity it is known that no certificate is needed). * hx/push-atomic-with-cert: send-pack: run GPG after atomic push checking
2020-09-25Merge branch 'ld/p4-unshelve-fix'Libravatar Junio C Hamano1-1/+4
The "unshelve" subcommand of "git p4" used incorrectly used commit^N where it meant to say commit~N to name the Nth generation ancestor, which has been corrected. * ld/p4-unshelve-fix: git-p4: use HEAD~$n to find parent commit for unshelve git-p4 unshelve: adding a commit breaks git-p4 unshelve
2020-09-25Merge branch 'jx/proc-receive-hook'Libravatar Junio C Hamano37-1/+3396
"git receive-pack" that accepts requests by "git push" learned to outsource most of the ref updates to the new "proc-receive" hook. * jx/proc-receive-hook: doc: add documentation for the proc-receive hook transport: parse report options for tracking refs t5411: test updates of remote-tracking branches receive-pack: new config receive.procReceiveRefs doc: add document for capability report-status-v2 New capability "report-status-v2" for git-push receive-pack: feed report options to post-receive receive-pack: add new proc-receive hook t5411: add basic test cases for proc-receive hook transport: not report a non-head push as a branch
2020-09-25Merge branch 'ds/maintenance-part-1'Libravatar Junio C Hamano4-2/+100
A "git gc"'s big brother has been introduced to take care of more repository maintenance tasks, not limited to the object database cleaning. * ds/maintenance-part-1: maintenance: add trace2 regions for task execution maintenance: add auto condition for commit-graph task maintenance: use pointers to check --auto maintenance: create maintenance.<task>.enabled config maintenance: take a lock on the objects directory maintenance: add --task option maintenance: add commit-graph task maintenance: initialize task array maintenance: replace run_auto_gc() maintenance: add --quiet option maintenance: create basic maintenance runner
2020-09-25t1506: rev-parse A..B and A...BLibravatar Junio C Hamano1-0/+18
Because these constructs can be used to parse user input to be passed to rev-list --objects, e.g. range=$(git rev-parse v1.0..v2.0) && git rev-list --objects $range | git pack-objects --stdin the endpoints (v1.0 and v2.0 in the example) are shown without peeling them to underlying commits, even when they are annotated tags. Make sure it stays that way. While at it, ensure "rev-parse A...B" also keeps the endpoints A and B unpeeled, even though the negative side (i.e. the merge-base between A and B) has to become a commit. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-25bisect: don't use invalid oid as rev when startingLibravatar Christian Couder1-0/+7
In 06f5608c14 (bisect--helper: `bisect_start` shell function partially in C, 2019-01-02), we changed the following shell code: - rev=$(git rev-parse -q --verify "$arg^{commit}") || { - test $has_double_dash -eq 1 && - die "$(eval_gettext "'\$arg' does not appear to be a valid revision")" - break - } - revs="$revs $rev" into: + char *commit_id = xstrfmt("%s^{commit}", arg); + if (get_oid(commit_id, &oid) && has_double_dash) + die(_("'%s' does not appear to be a valid " + "revision"), arg); + + string_list_append(&revs, oid_to_hex(&oid)); + free(commit_id); In case of an invalid "arg" when "has_double_dash" is false, the old code would "break" out of the argument loop. In the new C code though, `oid_to_hex(&oid)` is unconditonally appended to "revs". This is wrong first because "oid" is junk as `get_oid(commit_id, &oid)` failed and second because it doesn't break out of the argument loop. Not breaking out of the argument loop means that "arg" is then not treated as a path restriction (which is wrong). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-24pull: don't warn if pull.ff has been setLibravatar Alex Henrie1-1/+20
A user who understands enough to set pull.ff does not need additional instructions. Signed-off-by: Alex Henrie <alexhenrie24@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>