On 2013-12-09 23.10, Junio C Hamano wrote:
> 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).
> - 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...
Thanks for the analysis: I thing the patch isn't the way to go.
The regression in t5541 was introduced in f9e3c6bebb89de12.
Which was a cleanup to previous commits:
"transport-helper: add 'force' to 'export' helpers"
So reverting f9e3c6bebb89de fixes t5541, but breaks
Felipe, could you have a look, please ?
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