Torsten Bögershausen <tbo...@web.de> writes:
> The old log-line looked like this:
> + 9d498b0...8598732 master -> master (forced update)
> And the new one like this:
> 9d498b0..8598732 master -> master
>
> - Loosen the grep pattern by not demanding "(forced update)"
Hmm, what is the reason for the change the output? The output this
piece is testing is the result of this:
git push origin master:retsam
echo "change changed" > path2 &&
git commit -a -m path2 --amend &&
# push master too; this ensures there is at least one '"'push'"'
command to
# the remote helper and triggers interaction with the helper.
test_must_fail git push -v origin +master master:retsam >output 2>&1'
This is run inside test_repo_clone, which has /smart/test_repo.git
as its origin, which in turn has 'master' branch (and nothing else).
It
- pushes master to another branch retsam;
- amends its 'master';
- attempts to push the updated master to force-update master, and
also retsam without forcing. The latter needs to be forced to
succeed, and that is why we expect it to fail.
If the output from the push process says
+ 9d498b0...8598732 master -> master (forced update)
! [rejected] master -> retsam (non-fast-forward)
error: failed to push some refs to '../test_repo_copy/'
I think that is a good thing to do, no? After all, that is what we
show with Git native transports.
Is this patch merely matching a test to a broken behaviour of some
sort? Puzzled...
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
