Break down the cases in which "git push" fails due to non-ff into
three categories, and give separate advise messages for each case.
By Christopher Tiwald (2) and Jeff King (1)
* ct/advise-push-default:
Fix httpd tests that broke when non-ff push advice changed
clean up struct ref's nonfastforward field
push: Provide situational hints for non-fast-forward errors
When PATH contains an unreadable directory, alias expansion code did not
kick in, and failed with an error that said "git-subcmd" was not found.
By Jeff King (1) and Ramsay Jones (1)
* jk/run-command-eacces:
run-command: treat inaccessible directories as ENOENT
compat/mingw.[ch]: Change return type of exec functions to int
Fix broken 'push to upstream' implementation. "git push $there" without
refspec, when the current branch is set to push to a remote different from
$there, used to push to $there using the upstream information to a remote
unreleated to $there.
* jc/push-upstream-sanity:
push: error out when the "upstream" semantics does not make sense
The "fmt-merge-msg" command learns to list the primary contributors
involved in the side topic you are merging.
* jc/fmt-merge-msg-people:
fmt-merge-msg: show those involved in a merged series
Excludes conflicted paths from "add -p" processing, as it is not prepared
to handle them.
By Jeff King
* jk/add-p-skip-conflicts:
add--interactive: ignore unmerged entries in patch mode
When "git commit --template F" errors out because the user did not touch
the message, it claimed that it aborts due to "empty message", which was
utterly wrong.
By Junio C Hamano (4) and Adam Monsen (1)
* jc/commit-unedited-template:
Documentation/git-commit: rephrase the "initial-ness" of templates
git-commit.txt: clarify -t requires editing message
commit: rephrase the error when user did not touch templated log message
commit: do not trigger bogus "has templated message edited" check
t7501: test the right kind of breakage
Makes 'snapshot' request to "gitweb" honor If-Modified-Since: header,
based on the commit date.
By W. Trevor King
* wk/gitweb-snapshot-use-if-modified-since:
gitweb: add If-Modified-Since handling to git_snapshot().
gitweb: refactor If-Modified-Since handling
gitweb: add `status` headers to git_feed() responses.
The smart-http backend used to always override GIT_COMMITTER_* variables
with REMOTE_USER and REMOTE_ADDR.
By Jeff King
* jk/http-backend-keep-committer-ident-env:
http-backend: respect existing GIT_COMMITTER_* variables
Forbids rename detection logic from matching two empty files as renames
during merge-recursive to prevent mismerges.
By Jeff King
* jk/diff-no-rename-empty:
merge-recursive: don't detect renames of empty files
teach diffcore-rename to optionally ignore empty content
make is_empty_blob_sha1 available everywhere
drop casts from users EMPTY_TREE_SHA1_BIN
"git clean -d -f" (not "-d -f -f") is supposed to protect nested working
trees of independent git repositories that exist in the current project
working tree from getting removed, but the protection applied only to such
working trees that are at the top-level of the current project by mistake.
* jc/maint-clean-nested-worktree-in-subdir:
clean: preserve nested git worktree in subdirectories
Minor improvement to t0303.
By Zbigniew Jędrzejewski-Szmek
* zj/test-cred-helper-nicer-prove:
t0303: resurrect commit message as test documentation
t0303: immediately bail out w/o GIT_TEST_CREDENTIAL_HELPER
Running "notes merge --commit" failed to perform correctly when run
from any directory inside $GIT_DIR/. When "notes merge" stops with
conflicts, $GIT_DIR/NOTES_MERGE_WORKTREE is the place a user edits
to resolve it.
By Johan Herland (3) and Junio C Hamano (1)
* jh/notes-merge-in-git-dir-worktree:
notes-merge: Don't remove .git/NOTES_MERGE_WORKTREE; it may be the user's cwd
notes-merge: use opendir/readdir instead of using read_directory()
t3310: illustrate failure to "notes merge --commit" inside $GIT_DIR/
remove_dir_recursively(): Add flag for skipping removal of toplevel dir
The regexp configured with wordregex was incorrectly reused across files.
By Thomas Rast (2) and Johannes Sixt (1)
* tr/maint-word-diff-regex-sticky:
diff: tweak a _copy_ of diff_options with word-diff
diff: refactor the word-diff setup from builtin_diff_cmd
t4034: diff.*.wordregex should not be "sticky" in --word-diff
Some tests checked the "diff --stat" output when they do not have to,
which unnecessarily made things harder to verify under GETTEXT_POISON.
By Jonathan Nieder
* jn/diffstat-tests:
diffstat summary line varies by locale: miscellany
test: use numstat instead of diffstat in binary-diff test
test: use --numstat instead of --stat in "git stash show" tests
test: test cherry-pick functionality and output separately
test: modernize funny-names test style
test: use numstat instead of diffstat in funny-names test
test: use test_i18ncmp when checking --stat output
"git commit --author=$name" did not tell the name that was being recorded
in the resulting commit to hooks, even though it does do so when the end
user overrode the authorship via the "GIT_AUTHOR_NAME" environment
variable.
* jc/commit-hook-authorship:
commit: pass author/committer info to hooks
t7503: does pre-commit-hook learn authorship?
ident.c: add split_ident_line() to parse formatted ident line
Use API to read blob data in smaller chunks in more places to reduce the
memory footprint.
By Nguyễn Thái Ngọc Duy (6) and Junio C Hamano (1)
* nd/stream-more:
update-server-info: respect core.bigfilethreshold
fsck: use streaming API for writing lost-found blobs
show: use streaming API for showing blobs
parse_object: avoid putting whole blob in core
cat-file: use streaming API to print blobs
Add more large blob test cases
streaming: make streaming-write-entry to be more reusable
When execvp reports EACCES, it can be one of two things:
1. We found a file to execute, but did not have
permissions to do so.
2. We did not have permissions to look in some directory
in the $PATH.
In the former case, we want to consider this a
permissions problem and report it to the user as such (since
getting this for something like "git foo" is likely a
configuration error).
In the latter case, there is a good chance that the
inaccessible directory does not contain anything of
interest. Reporting "permission denied" is confusing to the
user (and prevents our usual "did you mean...?" lookup). It
also prevents git from trying alias lookup, since we do so
only when an external command does not exist (not when it
exists but has an error).
This patch detects EACCES from execvp, checks whether we are
in case (2), and if so converts errno to ENOENT. This
behavior matches that of "bash" (but not of simpler shells
that use execvp more directly, like "dash").
Test stolen from Junio.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The user can say "git push" without specifying any refspec. When using
the "upstream" semantics via the push.default configuration, the user
wants to update the "upstream" branch of the current branch, which is the
branch at a remote repository the current branch is set to integrate with,
with this command.
However, there are cases that such a "git push" that uses the "upstream"
semantics does not make sense:
- The current branch does not have branch.$name.remote configured. By
definition, "git push" that does not name where to push to will not
know where to push to. The user may explicitly say "git push $there",
but again, by definition, no branch at repository $there is set to
integrate with the current branch in this case and we wouldn't know
which remote branch to update.
- The current branch does have branch.$name.remote configured, but it
does not specify branch.$name.merge that names what branch at the
remote this branch integrates with. "git push" knows where to push in
this case (or the user may explicitly say "git push $remote" to tell us
where to push), but we do not know which remote branch to update.
- The current branch does have its remote and upstream branch configured,
but the user said "git push $there", where $there is not the remote
named by "branch.$name.remote". By definition, no branch at repository
$there is set to integrate with the current branch in this case, and
this push is not meant to update any branch at the remote repository
$there.
The first two cases were already checked correctly, but the third case was
not checked and we ended up updating the branch named branch.$name.merge
at repository $there, which was totally bogus.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "add -p" sees an unmerged entry, it shows the combined
diff and then immediately skips the hunk. This can be
confusing in a variety of ways, depending on whether there
are other changes to stage (in which case you get the
superfluous combined diff output in between other hunks) or
not (in which case you get the combined diff and the program
exits immediately, rather than seeing "No changes").
The current behavior was not planned, and is just what the
implementation happens to do. Instead, let's explicitly
remove unmerged entries from our list of modified files, and
print a warning that we are ignoring them.
We can cheaply find which entries are unmerged by adding
"--raw" output to the "diff-files --numstat" we already run.
There is one non-obvious thing we must change when parsing
this combined output. Before this patch, when we saw a
numstat line for a file that did not have index changes, we
would create a new record with 'unchanged' in the 'INDEX'
field. Because "--raw" comes before "--numstat", we must
move this special-case down to the raw-line case (and it is
sufficient to move it rather than handle it in both places,
since any file which has a --numstat will also have a --raw
entry).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the user exited editor without editing the commit log template given
by "git commit -t <template>", the commit was aborted (correct) with an
error message that said "due to empty commit message" (incorrect).
This was because the original template support was done by piggybacking on
the check to detect an empty log message. Split the codepaths into two
independent checks to clarify the error.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "-t template" and "-F msg" options are both given (or worse yet,
there is "commit.template" configuration but a message is given in some
other way), the documentation says that template is ignored. However,
the "has the user edited the message?" check still used the contents of
the template file as the basis of the emptyness check.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These tests try to run "git commit" with various "forbidden" combinations
of options and expect the command to fail, but they do so without having
any change added to the index. We wouldn't be able to catch breakages
that would allow these combinations by mistake with them because the
command will fail with "nothing to commit" anyway.
Make sure we have something added to the index before running the command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The http-backend program sets default GIT_COMMITTER_NAME and
GIT_COMMITTER_EMAIL variables based on the REMOTE_USER and
REMOTE_ADDR variables provided by the webserver. However, it
unconditionally overwrites any existing GIT_COMMITTER
variables, which may have been customized by site-specific
code in the webserver (or in a script wrapping http-backend).
Let's leave those variables intact if they already exist,
assuming that any such configuration was intentional. There
is a slight chance of a regression if somebody has set
GIT_COMMITTER_* for the entire webserver, not intending it
to leak through http-backend. We could protect against this
by passing the information in alternate variables. However,
it seems unlikely that anyone will care about that
regression, and there is value in the simplicity of using
the common variable names that are used elsewhere in git.
While we're tweaking the environment-handling in
http-backend, let's switch it to use argv_array to handle
the list of variables. That makes the memory management much
simpler.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because snapshots can be large, you can save some bandwidth by
supporting caching via If-Modified-Since. This patch adds support for
the i-m-s request to git_snapshot() if the request is a commit.
Requests for snapshots of trees, which lack well defined timestamps,
are still handled as they were before.
Signed-off-by: W Trevor King <wking@drexel.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current gitweb only generates Last-Modified and handles
If-Modified-Since headers for the git_feed action. This patch breaks
the Last-Modified and If-Modified-Since handling code out from
git_feed into a new function exit_if_unmodified_since. This makes the
code easy to reuse for other actions.
Only gitweb actions which can easily calculate a modification time
should use exit_if_unmodified_since, as the goal is to balance local
processing time vs. upload bandwidth.
Signed-off-by: W Trevor King <wking@drexel.edu>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
$COLUMNS must be unset to not interfere with the tests. The tests
already ignore the terminal size because output is redirected to a
file, but COLUMNS overrides terminal size detection and changes the
test output away from the standard 80.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge-recursive detects renames so that if one side modifies
"foo" and the other side moves it to "bar", the modification
is applied to "bar". However, our rename detection is based
on content analysis, it can be wrong (i.e., two files were
not intended as a rename, but just happen to have the same
or similar content).
This is quite rare if the files actually contain content,
since two unrelated files are unlikely to have exactly the
same content. However, empty files present a problem, in
that there is nothing to analyze. An uninteresting
placeholder file with zero bytes may or may not be related
to a placeholder file with another name.
The result is that adding content to an empty file may cause
confusion if the other side of a merge removed it; your
content may end up in another random placeholder file that
was added.
Let's err on the side of caution and not consider empty
files as renames. This will cause a modify/delete conflict
on the merge, which will let the user sort it out
themselves.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-difftool relies on the ability to forward unknown arguments
to the git-diff command. Add a test to ensure that this works
as advertised.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Andrew Sayers noticed that the svn-fe | git fast-import pipeline
mishandles a subversion history that copies the root directory to a
sub-directory (e.g. doing `svn cp . trunk` to standardise your
layout). As David Barr explained, the bug arises when the following
command is sent to git fast-import:
'ls' SP ':1' SP LF
Instead of reading back what is at the root of r1, it unconditionally
reports the path as missing.
After sleeping on it, here are two patches for 'maint'. One plugs a
memory leak. The other ensures that trying to pass an empty path to
the 'ls' command results in an error message that can help the
frontend author instead of the silently broken conversion Andrew
found.
Then we can carefully add 'ls ""' support in 1.7.11.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIbBAABCAAGBQJPWtgPAAoJEN/Gce6zM/olpU4P92DnurNCuUOsCIOVvEHT7YC+
JdBou7wDKug2U0XH4yvTCglJZQ+zWpoobPoJlGu4c+RPWYGoUnOvc2jUmhFGD2r4
jLlNhq3Uob4CSdEA8JLz8IOvgW41kc2LuUsZrr19dC3eS/19U72NQpD5nA958wZw
xmvcu1DjhrsYHSdh4azg0Ccsp3PzesssCGJSckKoYpOZSlbznK3Dyn2KnLPZvAmx
fF6uyPAZXKsKDOyVUPczIQ+mitb5YhOa3eFDcZk/EBM1LUCqbE0qmFyPhFqtE2pP
f0BcG2MwXc6S8FIRTSkzxV3WP8Cl5+3Y3LX+aB9Y5Zl7Vx1LBdDEhEZS0DkJFW1u
c/64Ge89FD/mSKpJfu8iZdga+qalyF1u5fPPFvOKV3p6UO1ou1RuIVEDMUhMzPhi
244i7VnaPq232aMr8Jn4eAnpg+mZpOdDuqsJn4Q/BOpJ2D5UmKzja4LUZk2tkmgh
EzGYLbs//TZXKjeNGH1rBdbW9lO0fU8oGRaTKiRwWTQVAJ48hUlOYfMBsWvUnvI6
A5ar/iT8UthEc54OZIkBefjpFrwIXl3wG1iafDY8Z1rcnGsbH9MpNFLFxcoGQTBJ
9A6ZyqL7dEKg2SWfESXf93xkF/fFZYl+0jFm+VNuJUzkrsvoi4tkxs/3qxaE74Kb
zQtYbp/z+KWFh4eg830=
=wrup
-----END PGP SIGNATURE-----
Merge "two fixes for fast-import's 'ls' command" from Jonathan
Andrew Sayers noticed that the svn-fe | git fast-import pipeline
mishandles a subversion history that copies the root directory to a
sub-directory (e.g. doing `svn cp . trunk` to standardise your
layout). As David Barr explained, the bug arises when the following
command is sent to git fast-import:
'ls' SP ':1' SP LF
Instead of reading back what is at the root of r1, it unconditionally
reports the path as missing.
After sleeping on it, here are two patches for 'maint'. One plugs a
memory leak. The other ensures that trying to pass an empty path to
the 'ls' command results in an error message that can help the
frontend author instead of the silently broken conversion Andrew
found.
Then we can carefully add 'ls ""' support in 1.7.11.
* commit 'refs/pull-request-tags/jn/maint-fast-import-empty-ls':
fast-import: don't allow 'ls' of path with empty components
fast-import: leakfix for 'ls' of dirty trees
remove_dir_recursively() has a check to avoid removing the directory it
was asked to remove without recursing into it and report success when the
directory is the top level of a working tree of a nested git repository,
to protect such a repository from "clean -f" (without double -f). If a
working tree of a nested git repository is in a subdirectory of a toplevel
project, however, this protection did not apply by mistake; we forgot to
pass the REMOVE_DIR_KEEP_NESTED_GIT down to the recursive removal
codepath.
This requires us to also teach the higher level not to remove the
directory it is asked to remove, when the recursed invocation did not
remove the directory it was asked to remove due to a nested git
repository, as it is not an error to leave the parent directories of such
a nested repository.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a manual notes merge is committed or aborted, we need to remove the
temporary worktree at .git/NOTES_MERGE_WORKTREE. However, removing the
entire directory is not good if the user ran the 'git notes merge
--commit/--abort' from within that directory. On Windows, the directory
removal would simply fail, while on POSIX systems, users would suddenly
find themselves in an invalid current directory.
Therefore, instead of deleting the entire directory, we delete everything
_within_ the directory, and leave the (empty) directory in place.
This would cause a subsequent notes merge to abort, complaining about a
previous - unfinished - notes merge (due to the presence of
.git/NOTES_MERGE_WORKTREE), so we also need to adjust this check to only
trigger when .git/NOTES_MERGE_WORKTREE is non-empty.
Finally, adjust the t3310 manual notes merge testcases to correctly handle
the existence of an empty .git/NOTES_MERGE_WORKTREE directory.
Inspired-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
notes_merge_commit() only needs to list all entries (non-recursively)
under a directory, which can be easily accomplished with
opendir/readdir and would be more lightweight than read_directory().
read_directory() is designed to list paths inside a working
directory. Using it outside of its scope may lead to undesired effects.
Apparently, one of the undesired effects of read_directory() is that it
doesn't deal with being given absolute paths. This creates problems for
notes_merge_commit() when git_path() returns an absolute path, which
happens when the current working directory is in a subdirectory of the
.git directory.
Originally-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Updated-by: Johan Herland <johan@herland.net>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'git notes merge' command expected to be run from the working
tree of the project being annotated, and did not anticipate getting
run inside $GIT_DIR/.
However, because we use $GIT_DIR/NOTES_MERGE_WORKTREE as a temporary
working space for the user to work on resolving conflicts, it is not
unreasonable for a user to run "git notes merge --commit" there. But
the command fails to do so.
Found-by: David Bremner <david@tethera.net>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The commit message which added those tests (861444f 't: add test
harness for external credential helpers' 2011-12-10) provided nice
documentation in the commit message. Let's make it more visible
by putting it in the test description.
The documentation is updated to reflect the fact that
GIT_TEST_CREDENTIAL_HELPER must be set for
GIT_TEST_CREDENTIAL_HELPER_TIMEOUT to be used
and GIT_TEST_CREDENTIAL_HELPER_SETUP can be used.
Based-on-commit-message-by: Jeff King <peff@peff.net>
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t0300-credential-helpers.sh requires GIT_TEST_CREDENTIAL_HELPER to be
configured to do something sensible. If it is not set, prove will say:
./t0303-credential-external.sh .. skipped: (no reason given)
which isn't very nice.
Use skip_all="..." && test_done to bail out immediately and provide a
nicer message. In case GIT_TEST_CREDENTIAL_HELPER is set, but the
timeout tests are skipped, mention GIT_TEST_CREDENTIAL_HELPER_TIMEOUT.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using word diff, the code sets the word_regex from various
defaults if it was not set already. The problem is that it does this
on the original diff_options, which will also be used in subsequent
diffs.
This means that when the word_regex is not given on the command line,
only the first diff for which a setting for word_regex (either from
attributes or diff.wordRegex) ever takes effect. This value then
propagates to the rest of the diff runs and in particular prevents
further attribute lookups.
Fix the problem of changing diff state once and for all, by working
with a _copy_ of the diff_options.
Noticed-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test case applies a custom wordRegex to one file in a diff, and expects
that the default word splitting applies to the second file in the diff.
But the custom wordRegex is also incorrectly used for the second file.
Helped-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As we already walk the history of the branch that gets merged to
come up with a short log, let's label it with names of the primary
authors, so that the user who summarizes the merge can easily give
credit to them in the log message.
Also infer the names of "lieutents" to help integrators at higher
level of the food-chain to give credit to them, by counting:
* The committer of the 'tip' commit that is merged
* The committer of merge commits that are merged
Often the first one gives the owner of the history being pulled, but
his last pull from his sublieutenants may have been a fast-forward,
in which case the first one would not be. The latter rule will
count the integrator of the history, so together it might be a
reasonable heuristics.
There are two special cases:
- The "author" credit is omitted when the series is written solely
by the same author who is making the merge. The name can be seen
on the "Author" line of the "git log" output to view the log
message anyway.
- The "lieutenant" credit is omitted when there is only one key
committer in the merged branch and it is the committer who is
making the merge. Typically this applies to the case where the
developer merges his own branch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These changes are in the same spirit as the six patches that
precede them, but they haven't been split into individually
justifiable patches yet.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git's --stat output is intended for humans and since v1.7.9.2~13
(2012-02-01) varies by locale. The tests in this script using "apply
--stat" are meant to check two things:
- how binary file changes are accounted for and printed in
git's diffstat format
- that "git apply" can parse the various forms of binary diff
Split these two kinds of check into separate tests, and use --numstat
instead of --stat in the latter. This way, we lose less test coverage
when git is being run without writing its output in the C locale (for
example because GETTEXT_POISON is enabled) and there are fewer tests
to change if the --stat output needs to be tweaked again.
While at it, use commands separated by && that read and write to
temporary files in place of pipelines so segfaults and other failures
in the upstream of the processing pipeline don't get hidden.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git's diff --stat output is intended for human consumption and
since v1.7.9.2~13 (2012-02-01) varies by locale. Add a test checking
that git stash show defaults to --stat and tweak the rest of the
"stash show" tests that showed a diffstat to use numstat.
This way, there are fewer tests to tweak if the diffstat format
changes again. This also improves test coverage when running tests
with git configured not to write its output in the C locale (e.g.,
via GETTEXT_POISON=Yes).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since v1.7.3-rc0~26^2~9 (revert: report success when using option
--strategy, 2010-07-14), the cherry-pick-many-commits test checks the
format of output written to the terminal during a cherry-pick sequence
in addition to the functionality. There is no reason those have to
be checked in the same test, though, and it has some downsides:
- when progress output is broken, the test result does not convey
whether the functionality was also broken or not
- it is not immediately obvious when reading that these checks are
meant to prevent regressions in details of the output format and
are not just a roundabout way to check functional details like the
number of commits produced
- there is a temptation to include the same kind of output checking
for every new cherry-pick test, which would make future changes
to the output unnecessarily difficult
Put the tests from v1.7.3-rc0~26^2~9 in separate assertions, following
the principle "test one feature at a time".
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
