[PATCH v2 1/2] rebase -i: clarify what happens on a failed `exec`

From: Johannes Schindelin We had not documented previously what happens when an `exec` command in an interactive rebase fails. Now we do. Signed-off-by: Johannes Schindelin --- Documentation/git-rebase.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git

[PATCH 0/9] Offer to run CI/PR builds in Visual Studio Team Services

For a long time already, we have Git's source code continuously tested via Travis CI, see e.g. https://travis-ci.org/git/git/builds/421738884. It has served us well, and more and more developers actually pay attention and benefit from the testing this gives us. It is also an invaluable tool for

[PATCH 6/9] Add a build definition for VSTS

From: Johannes Schindelin This commit adds a .vsts-ci.yml which is Visual Studio Team Services' equivalent to Travis CI's .travis.yml. To make things a bit easier to understand, we refrain from using the `matrix` feature here because (while it is powerful) it can be a bit confusing to users who

[PATCH 4/9] tests: optionally write results as JUnit-style .xml

From: Johannes Schindelin This will come in handy when publishing the results of Git's test suite during an automated VSTS CI run. Signed-off-by: Johannes Schindelin --- t/.gitignore | 1 + t/test-lib.sh | 98 +++ 2 files changed, 99

[PATCH 7/9] tests: include detailed trace logs with --write-junit-xml upon failure

From: Johannes Schindelin The JUnit XML format lends itself to be presented in a powerful UI, where you can drill down to the information you are interested in very quickly. For test failures, this usually means that you want to see the detailed trace of the failing tests. With Travis CI, we

[PATCH 1/9] ci: rename the library of common functions

From: Johannes Schindelin The name is hard-coded to reflect that we use Travis CI for continuous testing. In the next commits, we will extend this to be able use Visual Studio Team Services, too. So let's adjust the name to make it more generic. Signed-off-by: Johannes Schindelin ---

[PATCH 5/9] ci/lib.sh: add support for VSTS CI

From: Johannes Schindelin This patch introduces a conditional arm that defines some environment variables and a function that displays the URL given the job id (to identify previous runs for known-good trees). Signed-off-by: Johannes Schindelin --- ci/lib.sh | 23 +++ 1

[PATCH 8/9] tests: record more stderr with --write-junit-xml in case of failure

From: Johannes Schindelin Sometimes, failures in a test case are actually caused by issues in earlier test cases. To make it easier to see those issues, let's attach the output from before the failing test case (i.e. stdout/stderr since the previous failing test case, or the start of the test

[PATCH 3/9] test-date: add a subcommand to measure times in shell scripts

From: Johannes Schindelin In the next commit, we want to teach Git's test suite to optionally output test results in JUnit-style .xml files. These files contain information about the time spent. So we need a way to measure time. While we could use `date +%s` for that, this will give us only

[PATCH 9/9] README: add a build badge (status of the VSTS build)

From: Johannes Schindelin Just like so many other OSS projects, we now also have a build badge. Signed-off-by: Johannes Schindelin --- README.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/README.md b/README.md index f920a42fad..f260e78042 100644 --- a/README.md +++ b/README.md @@

[PATCH 2/9] ci/lib.sh: encapsulate Travis-specific things

From: Johannes Schindelin The upcoming patches will allow building git.git via VSTS CI, where variable names and URLs look a bit different than in Travis CI. Signed-off-by: Johannes Schindelin --- ci/install-dependencies.sh | 3 ++- ci/lib.sh | 44

[PATCH 1/1] rebase: fix GIT_REFLOG_ACTION regression

From: Johannes Schindelin The scripted version (partially) heeded the `GIT_REFLOG_ACTION` and when we converted to a built-in, this regressed. Fix that, and add a regression test, both with `GIT_REFLOG_ACTION` set and unset. Note: the reflog message for "rebase finished" did *not* heed

[PATCH 0/1] Fix built-in rebase regression noticed by Debian's dgit

It has been reported on the Debian bug tracker [https://bugs.debian.org/914695] that the built-in rebase regresses on the scripted version, and later details emerged that this has something to do with the reflog messages: they were different with the built-in rebase than with the scripted one.

[PATCH v2 0/1] Fix git rebase --stat -i

We're really entering obscure territory here, I would say. To trigger the bug, two things have to come together: the user must have asked for a diffstat afterwards, and the commits need to have been rebased onto a completely unrelated commit history (i.e. there must exist no merge base between

[PATCH v2 1/1] rebase --stat: fix when rebasing to an unrelated history

From: Johannes Schindelin When rebasing to a commit history that has no common commits with the current branch, there is no merge base. In diffstat mode, this means that we cannot compare to the merge base, but we have to compare to the empty tree instead. Also, if running in verbose diffstat

[PATCH 0/1] legacy-rebase: fix "regression"

This is a backport, really, to accommodate a new regression test that was introduced when the built-in rebase learned to validate the -C and --whitespace= arguments early. Johannes Schindelin (1): legacy-rebase: backport -C and --whitespace= checks git-legacy-rebase.sh | 8 1 file

[PATCH 1/1] legacy-rebase: backport -C and --whitespace= checks

From: Johannes Schindelin Since 04519d720114 (rebase: validate -C and --whitespace= parameters early, 2018-11-14), the built-in rebase validates the -C and --whitespace arguments early. As this commit also introduced a regression test for this, and as a later commit introduced the

[PATCH 0/1] Fix Windows build of next

The topic ot/ref-filter-object-info broke the Windows build since it entered pu, and as a consequence we have no test coverage of the other topics in pu. Sadly, this topic now advanced to next. Junio, I would like to ask you to merge this fix down to next and to advance to master together with

[PATCH 1/1] ref-filter: replace unportable `%lld` format

From: Johannes Schindelin The `%lld` format is supported on Linux and macOS, but not on Windows. This issue has been reported ten days ago (Message-ID: nycvar.qro.7.76.6.1811121300520...@tvgsbejvaqbjf.bet), but the corresponding topic still advanced to `next` in the meantime, breaking the

[PATCH 1/1] rebase: warn about the correct tree's OID

From: Johannes Schindelin This was a simple copy/paste error, and an obvious one at that: if we cannot fill the tree descriptor, we should show an error message about *that* tree, not another one. Signed-off-by: Johannes Schindelin --- builtin/rebase.c | 3 ++- 1 file changed, 2

[PATCH 0/1] rebase: warn about the correct tree's OID

A quick fix for a recent topic. Not overly critical, but I would deem this v2.20.0-rc1 material. Johannes Schindelin (1): rebase: warn about the correct tree's OID builtin/rebase.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) base-commit: bb75be6cb916297f271c846f2f9caa3daaaec718

[PATCH 1/1] rebase --stat: fix when rebasing to an unrelated history

From: Johannes Schindelin When rebasing to a commit history that has no common commits with the current branch, there is no merge base. The scripted version of the `git rebase` command was not prepared for that and spewed out fatal: ambiguous argument '': unknown revision or path not in

[PATCH 0/1] Fix git rebase --stat -i

We're really entering obscure territory here, I would say. To trigger the bug, two things have to come together: the user must have asked for a diffstat afterwards, and the commits need to have been rebased onto a completely unrelated commit history (i.e. there must exist no merge base between

<    1   2   3   4